General question about Python design goals
Antoon Pardon
apardon at forel.vub.ac.be
Thu Dec 1 14:47:02 EST 2005
On 2005-12-01, Steve Holden <steve at holdenweb.com> wrote:
> Antoon Pardon wrote:
>> On 2005-12-01, Fredrik Lundh <fredrik at pythonware.com> wrote:
>>
>>>Mike Meyer wrote:
>>>
>>>
>>>>So why the $*@& (please excuse my Perl) does "for x in 1, 2, 3" work?
>>>
>>>because the syntax says so:
>>>
>>> http://docs.python.org/ref/for.html
>>>
>>>
>>>>Seriously. Why doesn't this have to be phrased as "for x in list((1,
>>>>2, 3))", just like you have to write list((1, 2, 3)).count(1), etc.?
>>>
>>>because anything that supports [] can be iterated over.
>>
>>
>> This just begs the question. If tuples are supposed to be such
>> heterogenous sequences, one could indeed question why they
>> support [].
>>
> Presumably because it's necessary to extract the individual values
It isn't, The stated intent of tuples seems to suggest that packing
and unpacking should be sufficient.
> (though os.stat results recently became addressable by attribute name as
> well as by index, and this is an indication of the originally intended
> purpose of tuples).
>
>> And even if good arguments are given why tuples shouls support
>> [], the fact that the intention of tuples and list are so
>> different casts doubts on the argument that supporting []
>> is enough reason to support iteration.
>>
>> One could equally also argue that since iteration is at the heart
>> of methods like index, find and count, that supporting iteration
>> is sufficient reason to support these methods.
>>
> One could even go so far as to prepare a patch to implement the required
> methods and see if it were accepted (though wibbling is a much easier
> alternative).
That has been done and it was rejected.
> Personally I find the collective wisdom of the Python
> developers, while not infallible, a good guide as to what's pythonistic
> and what's not. YMMV.
That's because their decisions will shape python and thus decide
what is pythonic and what is not.
--
Antoon Pardon
More information about the Python-list
mailing list