>>> In my brief coding experience I have stumbled upon Python zfill(width)
>>> method,
[...]
>> It could be some sort of legacy. I imagine we will hear from some
>> more senior pythonists on this matter.
>>
> The documentation says "New in version 2.2.2".
But zfill has been in the string module for a lot longer.
--
Arnaud
> It can, after all, be implemented as a function, and in doing so
> (with the appropriate operator overloading) that function could
> work with multiple implementations of strings. Instead any
> implementation of a string must implement that method. That's a
> waste.
I'm not sure what you mean. I've written my own `split' function. I
don't believe that there would be any conflict if you wrote your
own `zfill' function. Or if there would be, I'd want to know before
I hurt myself.
regards
> Why does it suck? And why do people say 'suck' so much, especially in technical venues? :)
It's a technical term:
Also, because technical people are opinionated windbags. Goes with the
territory. :) Actually, it's partly because it's so easy to create
standards. You don't like X? Create your own language in which it
doesn't exist! You absolutely detest Y? Ignore it and use something
else! But since we can't ignore _everything_ we dislike, there ends up
a happy medium in which we all use the things that we dislike least,
all the while ranting about those aspects of them that "absolutely,
totally suck", and vowing that we could have done way better if we'd
been in the position of Some Famous Guy back when he had that perfect
opportunity to create a new and perfect standard, but he *blew it* by
having a small and narrow view, etc, etc, etc...
Of course, some of us manage to still be courteous and objective when
discussing the things that suck, while others just go off on lengthy
rants. And if you're willing to learn, it's not uncommon to start off
complaining and end up appreciating. :)
Chris Angelico
The gist of what I was saying is that it's possible to define
functions that do this "generically" so that one implementation of
zfill can work with multiple implementations of strings. Having to
reimplement every time when one implementation would do is bothersome
and generally isn't done unless it has to be (thus why mmap lacks a
zfill method). Having to do more work than necessary "sucks", as does
having partial str implementations that don't do everything str does.
Ideally, I would claim that if some interface will have multiple
implementations, it should have as few methods as possible to make
implementation as easy as possible, and move as much as possible
_away_ from methods and into functions that work with arbitrary
implementations of the interface. This minimizes the amount of work
that must be done for implementors and thus makes life better.
It's also true that it's "bad practice" to have objects with large
APIs, not for convenience reasons but because it increases object
coupling, something that "good" object oriented design seeks to
eliminate. The idea there is that the less ways you can have your
object interacted with / interact with other objects, the easier it is
to think of the way state flows. I agree with this in principle, but
it doesn't really matter for strings.
The situation I see with something like zfill as-a-method is that it
has nearly negligible benefit (less imports vs function?) and some
detriment. So I would conclude it should not exist. Other people look
at this differently.
> Also, because technical people are opinionated windbags.
Pardon?
Devin
The concrete string implementations would be descended from the
superclass and would still be able to override the additional methods
with more efficient code were desired, such as in the 'str' class.
This does sound better to me too!
Devin
No offense intended; just look at this list and you'll see how
opinionated people can be, and how willing to express those opinions
in many words! Frank and courteous exchange of views, one of the best
ways to learn about the subject matter... and about the other
programmers too.
ChrisA
That is kind of 'spot on' for me. Before I started using python, I
worked in rebol - where (at that time), there was a limited number
of function names available because of limited namespacing (and
the binary was a fraction the size of python). So I learned to
take that approach.
> Having to
> reimplement every time when one implementation would do is bothersome
> and generally isn't done unless it has to be (thus why mmap lacks a
> zfill method). Having to do more work than necessary "sucks", as does
> having partial str implementations that don't do everything str does.
>
> Ideally, I would claim that if some interface will have multiple
> implementations, it should have as few methods as possible to make
> implementation as easy as possible, and move as much as possible
> _away_ from methods and into functions that work with arbitrary
> implementations of the interface. This minimizes the amount of work
> that must be done for implementors and thus makes life better.
>
> It's also true that it's "bad practice" to have objects with large
> APIs, not for convenience reasons but because it increases object
> coupling, something that "good" object oriented design seeks to
> eliminate. The idea there is that the less ways you can have your
> object interacted with / interact with other objects, the easier it is
> to think of the way state flows. I agree with this in principle, but
> it doesn't really matter for strings.
>
> The situation I see with something like zfill as-a-method is that it
> has nearly negligible benefit (less imports vs function?) and some
> detriment. So I would conclude it should not exist. Other people look
> at this differently.
Good response.
Thank you.
I do, actually, but I don't need to add another newsgroup. Rick
provides plenty of material here, and I can easily sate myself in just
a few other places that I frequent. It's quite amusing to watch those
holy wars erupt...
And every once in a while, they actually prove quite educative. I'm
not sure how it happens, nor how to trigger it - hmm, perhaps this
should be the subject of a scientific paper. "On ranting newsgroups
and how to make them productive".
ChrisA
It did not. It mentioned only a pair of texts: the bible, and the Zen of
Python. Texts are not people, and we should not go out of our way to
protect them from jokes or criticism.
> It could certainly be _interpreted_ as an attack (and was interpreted
> that way), and that's really all that's necessary for a hostile
> environment.
Nonsense. *Any* joke could be interpreted as an attack; the issue is
whether it's reasonable to do so. Anyone who is so confused as to take a
joke about a book as an attack on people is being quite unreasonable, and
we should not restrain our jokes for the sake of that.
> I'm not saying we should censor ourselves exactly. I've always been
> opposed to harsh _rules_ about what's appropriate and what
> isn't. But I do think it's important to consider others' feelings.
Agreed. But only to the extent that attacks *on those people* are
concerned. Peoples feelings about ideas are not a consideration when
discussing ideas, and certainly not when joking about ideas.
> Just because it isn't an attack, doesn't mean it can't hurt peoples'
> feelings, and I think hurting peoples' feelings is something worth
> going out of your way to avoid.
There we disagree. The hurt feelings of someone who attaches their identity
to a text should not restrain our discourse.
> Anyway, if it was a joke before, it isn't when somebody starts calling
> some "group of people" "organised conspiracies to support and protect
> child molesters".
The group of people to whom that refers, the administrative hierarchy of
the Catholic Church, have been doing exactly what the quotation says.
I agree that's not a joke; it's a matter of fact, and relevant in the
context where it was mentioned.
> Is it OK to make fun of arbitrary ideas as "jokes"? I don't think so.
Yes, a thousand times yes. Ideas are not people, have no rights, and get no
exemption from criticism or dismissal or attack or ridicule.
> It seems, again, hurtful. Especially when the idea is totally unrelated.
That would eliminate just about every joke: a huge range of jokes *depend*
for their humour on connecting seemingly-unrelated ideas. So by your logic,
we don't get to make those jokes here.
> It's like we're having a discussion about dynamic typing and somebody
> blurts out "Hahaha, static typing is almost as dumb as Cartesian
> Dualism". The best case outcome is that nobody cares. The worse case
> outcomes go down to hurt feelings and flame wars from dualists.
And the joke would still be okay, and it would be silly for anyone to take
it as hurtful.
You can call such a joke off-topic, and I'd agree. You can say it's not
very funny, and I'd agree. You can say it's undeserving of a flame war, and
I'd agree wholeheartedly.
But whoever takes that joke and says it's deliberately hurtful is being
presumptuous and censorious and unreasonable. If they then castigate the
joker for supposedly hurting someone's feelings, it's at that point the
atmosphere turns hostile to discussion.
--
\ “The most dangerous man to any government is the man who is |
`\ able to think things out for himself, without regard to the |
_o__) prevailing superstitions and taboos.” —Henry L. Mencken |
Ben Finney <b...@benfinney.id.au>
alex23:
"""And like the Bible, the Zen was created by humans as a joke. If you're
taking it too seriously, that's your problem."""