General question about Python design goals

[Fredrik Lundh]

But you aren't illustrating that at all.

"But assume that I have some other use case"

</F>

 

[Duncan Booth]

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]

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

 

[Fredrik Lundh]

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 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.

 

[Paul Boddie]

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

 

[Aahz]

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).

 

[Christoph Zwerschke]

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.

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]

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]

- 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]

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.

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!

 

[Peter Hansen]

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]

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]

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]

there should be comma after "ist",

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

-- Christoph

 

[Mike Meyer]

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

 

[Bengt Richter]

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? ;-)

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]

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

 

[Antoon Pardon]

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.

 

[Steve Holden]

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