General question about Python design goals

[Christoph Zwerschke]

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

However when I ask such things I noticed I get answers like: "Is there a
use case?" "You can do it some other way so it is not worth bothering."

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

If I compare them with the "Zen of Python", I find some of the above:

consistency -> Special cases aren't special enough to break the rules
simplicity -> Simple is better than complex
aesthetics -> Beautiful is better than ugly

Actually, concerning the last two, you already need to understand the
Zen of Python to decide if something is "simple" or even "beautiful", so
they are not really suitable to *define* the Zen of Python. For me, a
programming language is beautiful if it is orthogonal and coherent. But
for others, this may be different. Somehow, I'm missing a direct
allusion to the following in the Zen of Python:

- orthogonality
- principle of least astonishment

Maybe I am I lacking the satori of a real Python Zen master?

-- Christoph

[Robert Kern]

Christoph Zwerschke wrote:

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

However when I ask such things I noticed I get answers like: "Is there a
use case?" "You can do it some other way so it is not worth bothering."

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

Yes. If it's not going to be used, then there's not much point.
Practicality beats purity, and all that.

However, I will note that if you were to present us with a working patch
with documentation and unittests, then you'll probably get responses
along the lines of "Thank you!", instead.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Paul Rubin]

Robert Kern <ro*********@gmail.com> writes:

Yes. If it's not going to be used, then there's not much point.
Practicality beats purity, and all that.

Geez man, "practicality beats purity" only means that if maintaining
purity of something is impractical, you can judiciously let purity
slide. It doesn't mean every slapdash kludge you can throw together
is acceptable for a widely-used distro, just because it works for the
cases you happened to think of at the moment you wrote it.

Wanting to handle the .count() parameters the same way for lists and
strings does not present any practical obstacles. So purity is not in
conflict with practicality there. The lack of orthogonality for that
operation is simply a wart.

[Robert Kern]

Paul Rubin wrote:

Robert Kern <ro*********@gmail.com> writes:

Yes. If it's not going to be used, then there's not much point.
Practicality beats purity, and all that.

Geez man, "practicality beats purity" only means that if maintaining
purity of something is impractical, you can judiciously let purity
slide. It doesn't mean every slapdash kludge you can throw together
is acceptable for a widely-used distro, just because it works for the
cases you happened to think of at the moment you wrote it.

Fine. Allow me to rephrase. Development is primarily motivated by
practical needs and guided by notions of purity. Use cases are the
primary tool for communicating those practical needs. If you can't think
of a single use case, what's the point of implementing something? Or
rather, why should someone else implement it if you don't know how you
would use it?

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[Aahz]

In article <dm**********@online.de>,
Christoph Zwerschke <ci**@online.de> wrote:

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?
Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.
Or, another example, the index() method has start and end parameters for
lists and strings. The count() method also has start and end parameters
for strings. But it has no such parameters for lists. Why?

That's a fair cop. Submit a patch and it'll probably get accepted.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

[Christoph Zwerschke]

>>Let me ask back: Do I really need to bother and justify it with a use

case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?

Robert Kern wrote:
Yes. If it's not going to be used, then there's not much point.
Practicality beats purity, and all that.
I have nothing against "practicality beats purity". But to stay with the
examples I have given, in how far is writing list(t).index(x) more
practical than t.index(x)?

And by the way, if we are speaking about practicality here, are we
speaking about practicality for the Python developers or for the Python
users? This may be sometimes be in opposition.

Let me give an extreme example: Assume the count() method for strings
would have been called "numberofsubstringsinthestring()" and I argue it
should be called "count()" because that is shorter and how it is called
for lists. What should I give as a "use case" here? Must I give "use
cases" if the issue is about convenience/simplicity/elegance?
However, I will note that if you were to present us with a working patch
with documentation and unittests, then you'll probably get responses
along the lines of "Thank you!", instead.

Not everybody has the time and skills to provide that. Ordinary people
from the Python user base should be given the opportunity to make
suggestions for improvement - of course not in the tone of "I
demand...", but they should not be automatically regarded as "demanding"
if they just utter their opinion or make a suggestion either.

Even if I had the time and skills, before starting to work on a patch,
unittests etc. I still would first discuss with others whether my
suggestion is reasonable and would be appreciated by the "user base",
developers and the BDFL. Just take the example of the following patch:
https://sourceforge.net/tracker/?fun...&group_id=5470

It was not rejected by reason of missing unittests or documentation, but
the very idea was rejected.

Actually, I'm not keen on being a protagonist for this issue or starting
a hard-bitten discussion about this and defend the idea if everybody is
against or nobody cares. It does not bother me that much either.

But it just led me to the general question: Which significance actually
have design features such as orthogonality for Python?

-- Christoph

[Christoph Zwerschke]

>>For instance, I just wanted to use the index() method on a tuple which

does not work. ...

Aahz wrote:
Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

-- Christoph

[Robert Kern]

Christoph Zwerschke wrote:

Let me ask back: Do I really need to bother and justify it with a use
case in a case where the language can be easily made more consistent or
orthogonal without breaking anything?
Robert Kern wrote:

Yes. If it's not going to be used, then there's not much point.
Practicality beats purity, and all that.
I have nothing against "practicality beats purity". But to stay with the
examples I have given, in how far is writing list(t).index(x) more
practical than t.index(x)?

I'm not arguing that the things you mentioned shouldn't be changed. I'm
saying that use cases really are important in making design decisions.
You just provided one. Congratulations.
And by the way, if we are speaking about practicality here, are we
speaking about practicality for the Python developers or for the Python
users? This may be sometimes be in opposition.

As Paul noted, it was a misuse of the phrase. I withdraw it.
However, I will note that if you were to present us with a working patch
with documentation and unittests, then you'll probably get responses
along the lines of "Thank you!", instead.

Not everybody has the time and skills to provide that. Ordinary people
from the Python user base should be given the opportunity to make
suggestions for improvement - of course not in the tone of "I
demand...", but they should not be automatically regarded as "demanding"
if they just utter their opinion or make a suggestion either.

Even if I had the time and skills, before starting to work on a patch,
unittests etc. I still would first discuss with others whether my
suggestion is reasonable and would be appreciated by the "user base",
developers and the BDFL. Just take the example of the following patch:
https://sourceforge.net/tracker/?fun...&group_id=5470

It was not rejected by reason of missing unittests or documentation, but
the very idea was rejected.

And it also appears to have nothing to do with the lack of proffered use
cases but (primarily) Guido's thoughts about how the different objects
are supposed to be used. That's why use cases are so important. They
allow developers to talk about real, concrete issues.

--
Robert Kern
ro*********@gmail.com

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

[bonono]

Christoph Zwerschke wrote:

For instance, I just wanted to use the index() method on a tuple which
does not work. ...

Aahz wrote:

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

That is the problem of the tutorial or manual, don't read them as if
they are ISO specs.

[Peter Hansen]

Christoph Zwerschke wrote:

But it just led me to the general question: Which significance actually
have design features such as orthogonality for Python?

Probably very little. Python has not so much been designed as evolved.
Plus it's a fairly mature language (over 14 years old), and I think in
such a case that elements of design tend to be obscured by the many
changes layered on top. (For example, I hardly recognize the C++ that I
learned in the language that struggles on today.)

While the goal of orthogonality may factor into some people's reasons
for implementing certain changes, it's not (apparently) a primary
motivation for many of the ones doing work on the Python core. If more
people with such motivations had been working on the core, it's likely
Python would have more of these sorts of "gaps" filled in.

(The corollary, of course, is that there would be other gaps, and they
would be more practical ones, so other people would probably be
suggesting things like "wouldn't it be good if Python had a Unicode type
instead of all these little-used functions that make the language nice
and orthogonal but aren't really necessary". ;-) )

-Peter

[Paul Rubin]

Robert Kern <ro*********@gmail.com> writes:

Fine. Allow me to rephrase. Development is primarily motivated by
practical needs and guided by notions of purity.
That's bogus; if there was a discrepancy someone noticed and had to
work around, there's already been a practical failure, just not a
severe one. Development should be guided by doing things right when
possible, making allowances for practical considerations that
sometimes call for compromise. It's generally far better to do
something right the first time than to do something broken and have to
fix it later. Those XP platitudes about prototyping and refactoring
are for when the program is still under development and the
requirements have not yet been discovered, and unfixed bogosity
affects just a few people (developers and testers). When a program
has been declared finished and shipped to millions of users, any
bogosity remaining in it has a much larger effect, so bogosity should
be minimized.
Use cases are the primary tool for communicating those practical
needs. If you can't think of a single use case, what's the point of
implementing something? Or rather, why should someone else implement
it if you don't know how you would use it?

I can't think of a single use case for the addition (+) operator
working where either of the operands happens to be the number
0x15f1ef02d9f0c2297e37d44236d8e8ddde4a34c96a820056 1de00492cb94b82 (a
random number I just got out of /dev/urandom). I've never heard of
any application using that number, and the chances of it happening by
coincidence are impossibly low. But if Python were coded in a way
that made the interpreter crash on seeing that number, I'd call that
a bug needing fixing.

[Aahz]

In article <dm**********@online.de>,
Christoph Zwerschke <ci**@online.de> wrote:

Aahz wrote:

Christoph deleted his own attribution:

For instance, I just wanted to use the index() method on a tuple which
does not work. ...

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

Then feel free to submit patches for the docs.

PS: If you want further responses from me, please follow standard Usenet
quoting conventions (like those above).
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

[Antoon Pardon]

Op 2005-11-28, Aahz schreef <aa**@pythoncraft.com>:

In article <dm**********@online.de>,
Christoph Zwerschke <ci**@online.de> wrote:

For instance, I just wanted to use the index() method on a tuple which
does not work. It only works on lists and strings, for no obvious
reason. Why not on all sequence types?

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

I find that a bit contradictory with the fact that if you want list like
structures as a dictionary key, you are mostly advised to cast them
as tuples.

So suppose I want a dictionary, where the keys are colours, represented
as RGB triplets of integers from 0 to 255. A number of things can be
checked by index-like methods.

e.g.

def iswhite(col):
return col.count(255) == 3

def primary(col):
return col.count(255) == 1 and col.count(0) == 2

def secondary(col):
return col.count(255) == 2 and col.count(0) == 1
So, what should I use to implement this? Whether I choose
lists or tuples, I will end up either copying a lot from
lists to tuples or vice versa, to get the functionality
I need, or I will have to implement functionality myself
that basically is already in the language.

I also find the use of C-structs and tuples completly different.
If I need a C-struct like object, I go for Bunch, Rec or something
similar. Something that uses field identifiers to address components,
Not something that uses indexing.

--
Antoon Pardon

[Fredrik Lundh]

Christoph Zwerschke wrote:

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

- A Foolish Consistency is the Hobgoblin of Little Minds
- Hypergeneralization Sucks

</F>

[Antoon Pardon]

Op 2005-11-28, Fredrik Lundh schreef <fr*****@pythonware.com>:

Christoph Zwerschke wrote:

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

- A Foolish Consistency is the Hobgoblin of Little Minds

What is so foolish about the consistency that all sequence types
have a count method?

The way this "pearl of wisdom" is used in this newsgroup, I expect
one day someone to use "+" for substraction and '-" for addition and
then when people complain about that not being consistent they get
answered by the above quote.

--
Antoon Pardon

[Sebastien Douche]

On 11/28/05, Christoph Zwerschke <ci**@online.de> wrote:

Sometimes I find myself stumbling over Python issues which have to do
with what I perceive as a lack of orthogonality.

I use this thread to asking on python conception : why python have so
many builtins ?
I cannot understand why we use a builtins for open a file. Is it a old
decision ? If anyone have a pointer of this or can explain me.

Regards.
--
Sébastien Douche <sd*****@gmail.com>

[Duncan Booth]

Antoon Pardon wrote:

So suppose I want a dictionary, where the keys are colours, represented
as RGB triplets of integers from 0 to 255. A number of things can be
checked by index-like methods.

e.g.

def iswhite(col):
return col.count(255) == 3

def primary(col):
return col.count(255) == 1 and col.count(0) == 2

def secondary(col):
return col.count(255) == 2 and col.count(0) == 1

Just because you *can* implement these by treating your colour like a list
doesn't make it a good idea. Treating them as opaque values makes these
particular tests clearer:

def iswhite(col):
return col==WHITE

def primary(col):
return col in (RED,GREEN,BLUE)

def secondary(col):
return col in (CYAN,MAGENTA,YELLOW)

If you relax your definition of primary to simply require that two planes
are black then you may have a case where you want to treat the colour
planes as a list, but if you convert it explicitly then you'll be better
placed to keep the code working when someone decides to add an alpha
channel or to switch the representation to CMYK.

def anyshadeprimary(col):
return [col.red, col.green, col.blue].count(0)==2
# or
return col.toRGB().count(0)==2

So it looks to me as though you want col to be a type (which might be a
subclass of tuple) but a list would be a mistake.

[Antoon Pardon]

Op 2005-11-28, Duncan Booth schreef <du**********@invalid.invalid>:

Antoon Pardon wrote:

So suppose I want a dictionary, where the keys are colours, represented
as RGB triplets of integers from 0 to 255. A number of things can be
checked by index-like methods.

e.g.

def iswhite(col):
return col.count(255) == 3

def primary(col):
return col.count(255) == 1 and col.count(0) == 2

def secondary(col):
return col.count(255) == 2 and col.count(0) == 1

Just because you *can* implement these by treating your colour like a list
doesn't make it a good idea. Treating them as opaque values makes these
particular tests clearer:

You are getting sidetracked. Whether this is the best possible
implementation here is not the issue. This example is just
to illustrate.

I'm sure I could come up with an other example where I would like
to have both some list method and use it as a dictionary key and
again people could start about that implementation having some
flaws and give better implementations.

I'm just illustrating that some list-like methods with tuples
could be usefull.

--
Antoon Pardon

[Duncan Booth]

Antoon Pardon wrote:

I'm sure I could come up with an other example where I would like
to have both some list method and use it as a dictionary key and
again people could start about that implementation having some
flaws and give better implementations.

I'm just illustrating that some list-like methods with tuples
could be usefull.

But you aren't illustrating that at all. You came up with an example which
showed, at least to me, a good argument why tuples should *not* have list
methods.

If you can come up with a better example that would be good; if any other
example is as flawed then perhaps it shows that your basic assumption is
wrong.

[Antoon Pardon]

Op 2005-11-28, Duncan Booth schreef <du**********@invalid.invalid>:

Antoon Pardon wrote:

I'm sure I could come up with an other example where I would like
to have both some list method and use it as a dictionary key and
again people could start about that implementation having some
flaws and give better implementations.

I'm just illustrating that some list-like methods with tuples
could be usefull.

But you aren't illustrating that at all. You came up with an example which
showed, at least to me, a good argument why tuples should *not* have list
methods.

No I gave an example, you would implement differently. But even
if you think my example is bad, that would make it a bad argument
for tuples having list methods. That is not the same as being
a good argument against tuples having list methods. The trouble is
to really convince would probably require a complete worked out module,
but then I don't have the time to come up with a complete worked out
module just to illustrate something. So I come up with just a skeleton
of something to get the idea across and what happens is that the
attention goes to how the skeleton could be approved in other ways,
instead of trying to understand what ideas are trying to be
communicated.

--
Antoon Pardon

[Fredrik Lundh]

Duncan Booth wrote:

I'm just illustrating that some list-like methods with tuples
could be usefull.

But you aren't illustrating that at all.

"But assume that I have some other use case"

</F>

[Duncan Booth]

Antoon Pardon wrote:

No I gave an example, you would implement differently. But even
if you think my example is bad, that would make it a bad argument
for tuples having list methods. That is not the same as being
a good argument against tuples having list methods.

Tuples don't have list methods, therefore any code which seems to require a
tuple with list methods should make you stop and consider whether your
design is wrong. Your example made me consider your design was wrong. If
tuples did have list methods you would have gone ahead with a poor design.

That is why I said that, to me, it is an argument against giving tuples the
additional methods. It is a fairly weak argument though, so if you do have
some other use case you could easily prove me wrong.

[Paul Boddie]

Antoon Pardon wrote:

Duncan Booth wrote:

But you aren't illustrating that at all. You came up with an example which
showed, at least to me, a good argument why tuples should *not* have list
methods.

For what it's worth, I don't agree with that analysis, but anyway...
No I gave an example, you would implement differently. But even
if you think my example is bad, that would make it a bad argument
for tuples having list methods. That is not the same as being
a good argument against tuples having list methods.

In this case, I rather agree with the pragmatic responses earlier in
the thread: that it was probably an oversight that tuples lack the
count, index and (arguably) sorted methods, and that patches would
probably be welcome to rectify this state of affairs. Personally, I
find certain sequence-like characteristics of strings more irritating
on occasions, and if one had to convert strings to lists in order to
iterate over the characters (as one has to do in various other
high-level languages), I probably wouldn't find that so inconvenient.
But then, such a change would probably disrupt the existence of other
useful aspects of strings: index-based access to characters, slicing,
and so on. I'm therefore not inclined to shout about such matters in
such a way that I then have to defend my subjective line of thinking
whilst proposing an objectively acceptable alternative.

I actually think it's good to question certain aspects of the language
in the way being done in this thread, despite unconvincing attempts to
defend the status quo (and the ever present threat of a giant hedgehog
emerging from behind a building with large signs reading "Pythonic" and
"Zen of Python" stuck on its spines), but I personally wouldn't spend
too much time on such matters myself.

Paul

[Aahz]

In article <11**********************@o13g2000cwo.googlegroups .com>,
Paul Boddie <pa**@boddie.org.uk> wrote:

In this case, I rather agree with the pragmatic responses earlier in
the thread: that it was probably an oversight that tuples lack the
count, index and (arguably) sorted methods, and that patches would
probably be welcome to rectify this state of affairs.

You're wrong. I don't have time/energy to look up the relevant posts,
but Guido has been extremely clear in the past that tuples are *NOT*
going to grow methods.
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

[Paul Boddie]

Aahz wrote:

You're wrong. I don't have time/energy to look up the relevant posts,
but Guido has been extremely clear in the past that tuples are *NOT*
going to grow methods.

Ah, I misread some of those other posts. Still, at least that is
consistent with saying that it wasn't worth spending much time on such
matters. ;-)

Paul

[Fredrik Lundh]

Christoph Zwerschke wrote:

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability.
both the tutorial and the FAQ discusses the difference in terms of use
cases and recommended usage.
Maybe I am I lacking the satori of a real Python Zen master?

I suggest you look up the phrase "bike shed effect". next, go read some
recent PEP:s to see what's really going on in the Python design universe.

</F>

[Aahz]

In article <ma***************************************@python. org>,
Sebastien Douche <sd*****@gmail.com> wrote:

I use this thread to asking on python conception : why python have so
many builtins ?
I cannot understand why we use a builtins for open a file. Is it a old
decision ? If anyone have a pointer of this or can explain me.

One of the primary goals for Python is to make it easy to use for new
programmers. Particularly for sysadmins, opening a file for reading and
writing is considered such a basic task that it's part of the builtins.

There are some builtins slated for removal in Python 3.0 (e.g. apply(),
which is superseded by *args/**kwargs being allows on the calling side).
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

[Christoph Zwerschke]

Fredrik Lundh schrieb:

Christoph Zwerschke wrote:

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability.

both the tutorial and the FAQ discusses the difference in terms of use
cases and recommended usage.

The tutorial does not speak about differences other than mutability. But
you're right, the C structs analogy is mentioned in the FAQ.

Maybe I am I lacking the satori of a real Python Zen master?

I suggest you look up the phrase "bike shed effect". next, go read some
recent PEP:s to see what's really going on in the Python design universe.

The bike shed effect is a good explanation and so true. About 8 years
ago when I started to work at my current working place at the university
I suggested that a bike shed should be provided for people like me.
Since then, a lot of million euro projects have been carried out, like
introducing SAP software and new projects are in progress. But my bike
still is getting wet and anyway, it's still bothering me.

-- Christoph

[Christoph Zwerschke]

Aahz wrote:

Christoph wrote:

Aahz wrote:

Christoph wrote:
For instance, I just wanted to use the index() method on a tuple which
does not work. ...

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.
But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

Then feel free to submit patches for the docs.

Why should I patch the docs to add things that don't seem plausible for
me? I'd rather change the behavior to be more consistent instead
tweaking the docs to somehow justify the inconsistent behavior.
PS: If you want further responses from me, please follow standard Usenet
quoting conventions (like those above).

I am tempted to answer, "A Foolish Consistency is the Hobgoblin of
Little Minds" ;-)

No honestly, it was not in bad faith. I'm just not a regular usenet user
and believed one attribution line per post should suffice. But reading
the conventions I agree that they make sense.

And I think it's a good analogy. Some people dislike Python's stringent
whitespace syntax and "one obvious way" rule because it does not give
them freedom to write programs in their individual style. But I don't
think it's "foolish consistency" - it simply makes programs of others
more easy to read, you can concentrate on the content and not the style.
It's the same reason why people use quoting conventions. And BTW, I
think that makes particularly suited for open source and XP projects.

-- Christoph

[Christoph Zwerschke]

Fredrik Lundh schrieb:

Christoph Zwerschke wrote:

What about design goals such as:

- orthogonality
- coherence, consistency
- principle of least astonishment ("Python fits my brain")
- simplicity ("kiss" principle)
- aesthetics, symmetry

Actually, which priority have the above design goals for Python? Are
other design goals considered more important?

- A Foolish Consistency is the Hobgoblin of Little Minds
- Hypergeneralization Sucks

Ok, these are nice aphorisms with some truth. But I had to think of the
German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein Genie
überblickt das Chaos." ("Those who try to keep things tidy are just too
lazy to search for searching - a genius surveys the chaos").

They remind you that consistency - as every good goal - can be
overemphasized and exaggerated on the cost of other good goals, but
otherwise they have little wisdom in the realm of programming.

In the original context (http://www.emersoncentral.com/selfreliance.htm)
and IIUC, the meaning of the "foolish consistency" aphorism is:

"A great mind will not stupidly think/work consistently from one day to
the next, but is able to throw away beloved ideas, beliefs, habits,
styles etc. if he/she finds something that is better, more true or more
appropriate under changed circumstances."

Try to transfer this to programming languages: "A great programming
language does not have to function consistently from one version to the
next, you can completely throw away a well-established syntax if you
find something better." I think this would not really be desirable.

Another problem I have with that aphorisms applied to Python is that it
has some undertone of "Python is only intended to be used by great
minds" and making it usable and understandable for "little minds" is no
design goal at all. That would be a very arrogant and elitarian view.
Little minds like me should be able to say "Python fits my brain" just
as great minds. Even kids can understand Python (there's a Germany book
"Python for Kids", http://www.way2python.de/pythonbuch/kids.html) and I
think i's not disqualifying Python as a "toy language", but I consider
it rather a strength of Python. Ok, there is even a book "C++ for kids",
but I think in reality it is intended for adult beginners...

Most of all, such solgans do not explain *when* consistency is to be
considered foolish and when it is wise. Are those who suggest changes in
order to make Python more consistent with itself foolish or are those
foolish who reject this, saying that "Python has always been like that,
nobody has cared in the past and we want to stay compatible". This could
be also considered a "foolish consistency".

A programming language is not a "work of art". If you are an artist, you
may break symmetry and introduce all kinds of unexpected effects.
Actually, as an artist, you purposfully want to provoke astonishment.
But if I am using a programming language or a user interface, I don't
want to be confronted with inconsistent behavior. Here, the "principle
of least astonishment" is much more helpful (in my little mind's humble
optionion).

-- Christoph

[Aahz]

In article <dm**********@online.de>,
Christoph Zwerschke <ci**@online.de> wrote:

Aahz wrote:

Christoph wrote:

Aahz wrote:
Christoph wrote:
>
>For instance, I just wanted to use the index() method on a tuple which
>does not work. ...

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

Then feel free to submit patches for the docs.

Why should I patch the docs to add things that don't seem plausible for
me? I'd rather change the behavior to be more consistent instead
tweaking the docs to somehow justify the inconsistent behavior.

The problem is that Guido really is the BDFL. Unless you change his mind
(and he has been historically firm about the place of tuples), your
option for improving things is to improve the docs, if you care.

PS: If you want further responses from me, please follow standard Usenet
quoting conventions (like those above).

I am tempted to answer, "A Foolish Consistency is the Hobgoblin of
Little Minds" ;-)

No honestly, it was not in bad faith. I'm just not a regular usenet user
and believed one attribution line per post should suffice. But reading
the conventions I agree that they make sense.

Thanks!
--
Aahz (aa**@pythoncraft.com) <*> http://www.pythoncraft.com/

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

[Peter Hansen]

Christoph Zwerschke wrote:

Ok, these are nice aphorisms with some truth. But I had to think of the
German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein Genie
überblickt das Chaos." ("Those who try to keep things tidy are just too
lazy to search for searching - a genius surveys the chaos").

Is that really the translation? "too lazy to search for searching"?
What does that mean?

Google translate doesn't help... here's it's rather comical attempt:

"Who order holds is only to putrid for looking for - a genius grasps the
chaos"

-Peter

[Christoph Zwerschke]

Peter Hansen schrieb:

Christoph Zwerschke wrote:

Ok, these are nice aphorisms with some truth. But I had to think of
the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein
Genie überblickt das Chaos." ("Those who try to keep things tidy are
just too lazy to search for searching - a genius surveys the chaos").

Is that really the translation? "too lazy to search for searching"?
What does that mean?

Sorry. Cancel either "to search" or "for searching". I noticed I made a
lot of typos in that posting. In the German sentence, there should be
comma after "ist", and "faul" should be written with a lowercase "f".
Probably this caused additional confusion for Google...

-- Christoph

[Paul Rubin]

Peter Hansen <pe***@engcorp.com> writes:

Christoph Zwerschke wrote:

Ok, these are nice aphorisms with some truth. But I had to think of
the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein
Genie überblickt das Chaos." ("Those who try to keep things tidy are
just too lazy to search for searching - a genius surveys the chaos").

Is that really the translation? "too lazy to search for searching"?
What does that mean?

It should just say "too lazy to search" or maybe "too lazy to be a
searcher".

[Christoph Zwerschke]

Christoph Zwerschke wrote:

there should be comma after "ist",

Sorry, *before* "ist". I should probably stop posting for today...

-- Christoph

[Mike Meyer]

Christoph Zwerschke <ci**@online.de> writes:

A programming language is not a "work of art". If you are an artist,
you may break symmetry and introduce all kinds of unexpected
effects. Actually, as an artist, you purposfully want to provoke
astonishment. But if I am using a programming language or a user
interface, I don't want to be confronted with inconsistent
behavior. Here, the "principle of least astonishment" is much more
helpful (in my little mind's humble optionion).

But a programming language (or UI) is not just a collection of syntax
and and interfaces - it's an implementation. You need to keep in mind
that "practicality beats purity". If following POLA makes the
implementation an order of magnitude slower or larger, then you don't
follow POLA - at least until you can do it without that cost.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Bengt Richter]

On 27 Nov 2005 21:01:49 -0800, aa**@pythoncraft.com (Aahz) wrote:

In article <dm**********@online.de>,
Christoph Zwerschke <ci**@online.de> wrote:

Aahz wrote:

Christoph deleted his own attribution:

For instance, I just wanted to use the index() method on a tuple which
does not work. ...

Because Guido believes that tuples should be primarily used as
lightweight replacements for C structs. Therefore they have minimal
functionality.

As has been pointed out list(atuple).alistmethod(thelistmethodsargs) works
to get the benefit of list methods. In fact, list(anyiterable).alistmethod(thelistmethodsargs)
works too. Maybe list is not the best possible unifier for defining sequence-applicable methods.
I'm getting at something ;-)

Tuples are iterable. Therefore, once a tuple is e.g. turned into an iterator object,
Guido's feelings about the appropriate uses for tuples have been laundered away.
Someone is saying "I want to treat this as a sequence" when they write, e.g., iter(atuple).

If iter were a type instead of a built-in function, it could have methods that
apply to all sequences. Then you could write iter(any_iterable).count(match_element)
and know that that .count is uniformly available that way for any sequence passed
to the iter constructor.

IMO this would be better than demanding that all iterable objects themselves have
all the handy sequence-applicable methods.

ISTM many of the itertools goodies could be written as methods of iter, especially if you expanded
the iter call signature to accept multiple iterables, so e.g., iter('abc', '12').zip()
would produce an iterator like izip. Note this iterator would also be an iter or iter subclass instance,
and so would have methods available so you could chain them like iter('abc','123').zip().slice(1,2)
(I am dropping the prefixed 'i'). Also, these methods might have useful variants controlled by arguments,
e.g., iter(seq1, seq2).zip(pad='<missing>') might insert the pad keyword argument (if present) for
to pad out shorter sequences to the same length as the longest, like map(None, ...)

IOW, all the methods that apply orthogonally to sequences should perhaps be methods
available to iter instances. Currently you can only pass a single iterable or
a callable, sentinel pair to iter, but that could be expanded.

Further example...

iter(open('afile')).filter(lambda line:line.strip().startswith('From:')

would return a suitable filtering iterator, which in turn would have further
iter methods available if desired, so

iter(open('afile')).filter(lambda line:line.strip().startswith('From:').len()

might return the length (hopefully optimized for iterators that have the opportunity to
pass though actual length from their source, but otherwise working through the sequence).
(Of course, if open returned a standard iter subclass instance, you wouldn't have
to write iter(open(...)))

ISTM this would be a powerful way of composing pipelined iterators and unifying treatment
of sequences, as well as providing a logical place to add useful general sequence-applicable methods.

Later you could talk about syntactic sugar for spelling e.g. iter(atuple).count(thing) more concisely.
Maybe a double attribute dot (for sequence mnemonic)? E.g., obj.. <=> iter(obj) so
atuple..count(thing)
would be sugar for
__builtins__.iter(atuple).count(thing)
(I added __builtins__ to let you be perverse and define a local iter for use as
iter(atuple).surprising(thing)
also if you wanted to). But sugar aside,
I think it would be nice just to have a subclassable iter type with good base methods.

But (perhaps ;-) the main point here is not my latest OTTOMH idea/BF.
The point is to illustrate that there may be unexplored avenues available to satify those
who say, "But a tuple is a sequence a lot like list, so why don't they have the same
handy sequence methods?" Which means that I suspect there is something like premature
NIH-idea-xenophobic rejection going on sometimes, where imagination might be more helpful
and a way could be found to make a concept fit satisfyingly in a place not immediately recognized.

IOW, I generally like orthogonality, so I sympathize with the desire to have .count available
easily for any sequence, including tuples. But I don't think that means that all iterable
objects should _themselves_ have all list methods etc.
Another idea would be to tag names with '!' to indicate that a name space "path" should be searched
before or after normal name search. So e.g. if there were a __nspath__ visible, e.g. like

__nspath__ == [__builtins__.__dict__, dict(index=lambda obj, el:list(obj).index(el))]

then

atuple.!index(42)

would mean something like (untested ;-)

(d['index'] for d in __nspath__ if 'index' in d).next().__get__(atuple, type(atuple))(42)

this could also be written as

atuple.index!(42)

which would mean if atuple had and index method, that would immediately satisfy the search, but
the search would continue at the '!' point if not. The default nspath could be in __builtins__
optimized unless a module gets a global __nspath__ at import time. But that's premature optimization ;-)

Hm, that means that obj.!method produces a bound method with a function
dynamically borrowed potentially from anywhere ;-) Hm2, should it be an error if there's no __get__, or
should that be a mechanism for supplycing a default attribute value through an extended
(by __nspath__) search?

Should I have started a new thread for this kind of idea musing? ;-)
But the problem is that the tutorials and manuals give the impression
that the difference between lists and tuples is only mutablity versus
immutability. They don't talk about such considerations and honestly
speaking even now I know that it does seem more plausible for me.

Then feel free to submit patches for the docs.

This is easy to say, and maybe the docs maintainers are accomodating,
but I'd be the average reader wouldn't have a concept of how a "patch"
should be prepared. I know the info is not far away in the python.org site
but still, is there an interface that will bring up a doc page in a browser
and let you select e.g. a paragraph and pop up a form for a before/after
rewrite proposal (maybe with integrated preview, a la slashdot submissions)?
That's wiki-like, but I'm thinking a tailored utility. Given reasonably
structured doc sources, I wouldn't think it would be too bad a project.
Not that I'm volunteering to write that particular thing ;-)

Regards,
Bengt Richter

[Mike Meyer]

bo**@oz.net (Bengt Richter) writes:

Then feel free to submit patches for the docs.

This is easy to say, and maybe the docs maintainers are accomodating,
but I'd be the average reader wouldn't have a concept of how a "patch"
should be prepared.

From what's been said here before, the doc committers aren't picky
about getting patches. That requires learning whatever doc format they
use, and they understand that that's a pretty hefty burden for a one
or two-paragraph tweak on the documentation. So submitting docs in
English works. Submitting patches works *better*, but not doing so
doesn't consign your suggestions to oblivion.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Antoon Pardon]

On 2005-11-28, Duncan Booth <du**********@invalid.invalid> wrote:

Antoon Pardon wrote:

No I gave an example, you would implement differently. But even
if you think my example is bad, that would make it a bad argument
for tuples having list methods. That is not the same as being
a good argument against tuples having list methods.

Tuples don't have list methods, therefore any code which seems to require a
tuple with list methods should make you stop and consider whether your
design is wrong.

IMO that is a non-sequitur, because that makes what is good or bad
design dependand on the language used.

If I have a design that seems to require tuples with a count method,
then wether that is a good or bad design doesn't depend on
whether or not python allows that or not.

--
Antoon Pardon

[Christoph Zwerschke]

Mike Meyer wrote:

Christoph Zwerschke wrote:

A programming language is not a "work of art". If you are an artist,
you may break symmetry and introduce all kinds of unexpected
effects. Actually, as an artist, you purposfully want to provoke
astonishment. But if I am using a programming language or a user
interface, I don't want to be confronted with inconsistent
behavior. Here, the "principle of least astonishment" is much more
helpful (in my little mind's humble optionion).

But a programming language (or UI) is not just a collection of syntax
and and interfaces - it's an implementation. You need to keep in mind
that "practicality beats purity". If following POLA makes the
implementation an order of magnitude slower or larger, then you don't
follow POLA - at least until you can do it without that cost.

I do not deny this. As an example, if tuples can be used as keys of
dicts, you might first naively assume that lists could also work. This
is not the case for practicality (performance) reasons and because it
would be difficult or impossible to guarantee the uniqueness of keys. In
this case, POLA is overruled by other goals or inherent necessities.

But that does not mean that POLA in itself is not an important guiding
principle for programming languages (or UI).

-- Christoph

[Steve Holden]

Christoph Zwerschke wrote:

Fredrik Lundh schrieb:

[...]

I suggest you look up the phrase "bike shed effect". next, go read some
recent PEP:s to see what's really going on in the Python design universe.

The bike shed effect is a good explanation and so true. About 8 years
ago when I started to work at my current working place at the university
I suggested that a bike shed should be provided for people like me.
Since then, a lot of million euro projects have been carried out, like
introducing SAP software and new projects are in progress. But my bike
still is getting wet and anyway, it's still bothering me.

Yes, but that's the academic world, and bike sheds are a real-world
requirement so they will tend to be ignored indefinitely.

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Bengt Richter]

On Tue, 29 Nov 2005 00:52:25 -0500, Mike Meyer <mw*@mired.org> wrote:

bo**@oz.net (Bengt Richter) writes:

Then feel free to submit patches for the docs.

This is easy to say, and maybe the docs maintainers are accomodating,
but I'd be the average reader wouldn't have a concept of how a "patch"
should be prepared.

From what's been said here before, the doc committers aren't picky
about getting patches. That requires learning whatever doc format they
use, and they understand that that's a pretty hefty burden for a one
or two-paragraph tweak on the documentation. So submitting docs in
English works. Submitting patches works *better*, but not doing so
doesn't consign your suggestions to oblivion.

Ok, sounds reasonable.
BTW, no opinion on iter as a type harboring sequence-applicable methods? ;-)

Regards,
Bengt Richter

[Sibylle Koczian]

Peter Hansen schrieb:

Christoph Zwerschke wrote:

Ok, these are nice aphorisms with some truth. But I had to think of
the German excuse "Wer Ordnung hält ist nur zu Faul zum Suchen - ein
Genie überblickt das Chaos." ("Those who try to keep things tidy are
just too lazy to search for searching - a genius surveys the chaos").

Is that really the translation? "too lazy to search for searching"?
What does that mean?

Google translate doesn't help... here's it's rather comical attempt:

"Who order holds is only to putrid for looking for - a genius grasps the
chaos"

Automated translation in a nutshell.

--
Dr. Sibylle Koczian
Universitaetsbibliothek, Abt. Naturwiss.
D-86135 Augsburg
e-mail : Si*************@Bibliothek.Uni-Augsburg.DE

[Fredrik Lundh]

Steve Holden wrote:

The bike shed effect is a good explanation and so true. About 8 years
ago when I started to work at my current working place at the university
I suggested that a bike shed should be provided for people like me.
Since then, a lot of million euro projects have been carried out, like
introducing SAP software and new projects are in progress. But my bike
still is getting wet and anyway, it's still bothering me.

Yes, but that's the academic world, and bike sheds are a real-world
requirement so they will tend to be ignored indefinitely.

on the other hand, it's also possible that there are perfectly usable ways
to keep bikes and bike seats dry where Christoph works, but that he prefers
not to use them because they're violating some design rule.

(this is related to the drain pipe effect, where engineers spend endless
hours talking about how to make it easier to climb the drain pipe, while
everyone uses the stairs...)

</F>

[Bengt Richter]

On 29 Nov 2005 08:27:43 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

On 2005-11-28, Duncan Booth <du**********@invalid.invalid> wrote:

Antoon Pardon wrote:

No I gave an example, you would implement differently. But even
if you think my example is bad, that would make it a bad argument
for tuples having list methods. That is not the same as being
a good argument against tuples having list methods.

Tuples don't have list methods, therefore any code which seems to require a
tuple with list methods should make you stop and consider whether your
design is wrong.

IMO that is a non-sequitur, because that makes what is good or bad
design dependand on the language used.

If I have a design that seems to require tuples with a count method,
then wether that is a good or bad design doesn't depend on
whether or not python allows that or not.

No, but if your requirement is to count __eq__ - matching items in a
tuple, maybe your sense of orthogonality ought to abstract out the
sequence aspect in some other way than seeing it as a seeming method
requirement for tuple. A tuple.count method has implications about
attribute access to a special object, tuple, which then you have
to deal with for every new object you introduce, unless you want to
inherit it from object, but that means object becomes a
mega swiss army knife in short order.

So IMO the thing is not to ask for a specific solution like "why
not a count method for tuples?" You'll just get answers to that literal
question, with some elaborations. Instead, if you put it in the form
of what your general requirement really is (I'm guessing ;-) which I
assume is to be able to apply list count method _functionality_ to
anything which quacks like a list, including tuples etc. In short,
anything iterable.

Now the problem is to bring program and data together with some
spelling in python. data.method() is certainly one spelling, but
so is method(data). You gain something either way. The first allows
you to associate the method and data without executing the method, i.e.,
data.method is a bound method object that has the data-method association
built in, and it can be passed around. method(data) does the call right
away and uses a diferent name space search path to find method, and is
not necessarily associated with type(data). To ask for common methods
for all objects that exhibit some similar aspect is to entangle their
types in some way or to duplicate stuff. Sometimes it's fine to
derive from a common base etc., but

why not a built-in count function that does something like (untested)

def count(obj, match_item, eq=operator.eq):
return sum(1 for item in iter(obj) if eq(item, match_item))

which would give a little flexibility about eq comparison as well as
wide applicability to any sequence? index too (untested)

def index(obj, match_item, eq=operator.eq):
try: return (i for i, item in enumerate(obj) if eq(item, match_item)).next()
except StopIteration: raise ValueError('index(seq, item): item not in seq')

why doesn't list have a find like str? ;-)

def find(obj, match_item, eq=operator.eq):
try: return (i for i, item in enumerate(obj) if eq(item, match_item)).next()
except StopIteration: return -1

One could create an alternate spelling for obj.count(thing) using the count function above.
You can spell it now as

count.__get__(obj, type(obj))(thing)

if you want to duplicate the effect of having the count function retrieved from type(obj)
as if it were a method defined there. Or you can spell it

count(obj)

which doesn't seem too bad ;-)
But now the problem is cluttering the __builtins__ space. So maybe it would be
better to write
from sequence_goodies import count
...
count(obj)

Do you really want a count method for tuple? Or is that maybe not as clean is
it seemed? All the issues aren't usually immediatly apparent, so IMO the more
we focus on abstract functionality desired, the more likely we will get
helpful solution ideas for a menu of choices, and avoid prematurely discussing
whether we should have pumpkin pie with or without whipped cream, when finally
we might all like strawberries and cream better, if someone had thought of it.

Regards,
Bengt Richter

[Christoph Zwerschke]

Fredrik Lundh wrote:

on the other hand, it's also possible that there are perfectly usable ways
to keep bikes and bike seats dry where Christoph works, but that he prefers
not to use them because they're violating some design rule.

Depends on how you understand "perfectly usable." My collegue always
carries his expensive racing bike to our office in the 3rd floor out of
fear it may get wet or stolen. But I think this is not very convenient
and I want to avoid discussions with our boss about skid marks on the
carpet and things like that. Probably that collegue would not complain
as well if he had to cast tuples to lists for counting items - you see,
people are different ;-)

-- Christoph

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

But a programming language (or UI) is not just a collection of syntax
and and interfaces - it's an implementation. You need to keep in mind
that "practicality beats purity".
An awful lot of the time in this newsgroup, "practicality beats
purity" translates as "the programmer can just be a lazy slob".
If following POLA makes the implementation an order of magnitude
slower or larger, then you don't follow POLA - at least until you
can do it without that cost.

If following POLA costs that much, at least in the kinds of examples
we talk about all the time here, something is probably wrong with the
implementation (or the design) to begin with.

[Mike Meyer]

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Mike Meyer <mw*@mired.org> writes:

But a programming language (or UI) is not just a collection of syntax
and and interfaces - it's an implementation. You need to keep in mind
that "practicality beats purity".

An awful lot of the time in this newsgroup, "practicality beats
purity" translates as "the programmer can just be a lazy slob".

You post that as if it were a bad thing.

If following POLA makes the implementation an order of magnitude
slower or larger, then you don't follow POLA - at least until you
can do it without that cost.

If following POLA costs that much, at least in the kinds of examples
we talk about all the time here, something is probably wrong with the
implementation (or the design) to begin with.

True, but not constructive. Knowing that something is wrong is
easy. Diagnosing the problem is harder. Curing it is even harder. And
unti you get to that last step, you haven't done anything to improve
the situation.

<mike
--
Mike Meyer <mw*@mired.org> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

An awful lot of the time in this newsgroup, "practicality beats
purity" translates as "the programmer can just be a lazy slob".

You post that as if it were a bad thing.

Yes. The idea of using a program that someone else wrote, is that
they do the work so I don't have to. If their doing less work means
that I have to do more, the program isn't as good as it might be.

A program like Python intended for wide distribution and use by large
numbers of people whose needs aren't known in advance, should do as
much to help its users as development resources allow.

Are you familiar with R. Gabriel's piece "Worse is better"? That's
not what I see "practicality beats purity" as being intended to mean.

If following POLA costs that much, at least in the kinds of examples
we talk about all the time here, something is probably wrong with the
implementation (or the design) to begin with.

True, but not constructive. Knowing that something is wrong is
easy. Diagnosing the problem is harder. Curing it is even harder.

Look at the list.count() example at the start of this thread.
Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat
Python by an order of magnitude. A suitably factored implementation
might handle lists and strings with the exact same code and not incur
any extra cost at all. That type of thing happens all the time here.

[bonono]

Paul Rubin wrote:

Look at the list.count() example at the start of this thread.
Diagnosing it isn't hard. Curing it isn't hard. It doesn't bloat
Python by an order of magnitude. A suitably factored implementation
might handle lists and strings with the exact same code and not incur
any extra cost at all. That type of thing happens all the time here.

I believe the language creator use the "lack of" as a way to
prevent/discourage that kind of usage. Just like the ternary
operator(still don't know why it is finally accepted). It is not a
problem(not having), it is a feature(to teach you program better), so
what cure are we talking about ?