Status of PEP's?

Carel Fellinger cfelling at iae.nl
Sat Mar 2 18:41:53 EST 2002


How strange the world is, I now end up defending a proposal I'm
against (or was against, I'm still in dubio)

Jeff Hinrichs <jlh at cox.net> wrote:

> "Carel Fellinger" <cfelling at iae.nl> wrote in message
> news:a5pmvd$fic$1 at animus.fel.iae.nl...
>> Jeff Hinrichs <jlh at cox.net> wrote:
>>
>> > What you are asking everyone to agree with is:
>> >         5 = [0,1,2,3,4]
>>
>> No he isn't:)  He explicitly says he doesn't think of sequences at all.
> If it walks like a duck and talks like a duck...
>   It's a duck.   How can one iterate over something that is not a
> sequence/collection?

This used to be the case in Python, but the invention of iterators
has changed the landscape.  The for-construct no longer works on
sequences, it works on iterable objects.  So it's not right anymore
to reject such a proposal based on that the thing isn't a sequence.
You now must reject it if you feel the thing can't be iterated over.
This may seem like a word play, but it isn't, it's a vital though
subtle difference.  And it took me, being an old farth, quit some
time to let it sink in.

>> ...
>> > If you were to restate the above as:
>> >        f(5)=[0,1,2,3,4]
>> > Then, I believe, that you wouldn't have any problem convincing a large
>> > majority that it is possible for f() to produce such an output.  That
> being
>>
>> And this is precisly what he's proposing, f is called iter in his
>> case.
> But this is already in the language.  It is called range/xrange.  I haven't
...

Ah, missing smiley.  The pun here was that the for loop calls the iter
function, so the sole 5 there actually is a iter(5) to the interpreter.
And f(5) turns into iter(5) when you replace f by iter:)

Apart from that, your point of lacking convincing arguments for change
is one of the reasons I'm still contemplating my stanze.

> a) readability
> b)robustness
> c)minimizing bugs

Ah my proposed change for down counting sure is a candidate for bug
minimalisation, as one often makes one-off errors in the range call
needed to achieve the same effect:)

>>He comes from the camp that sees everything as an object, so
...
> But I don't accept this.  **Not everything is an object.**  An apple is an

Fair, and as I explained in an other post quit close to my believes.
But it *is* a standard way of looking at the world in OO circles.

>>Like the `for'
>> construct recently got stretched to mean `over all lines' and `over
>> its keys' for text-files and dictionaries.  Admitted in those cases it
>> still was a clear `iterate over', but the what was debatable.
> The reason for this, is that it is natural to view a file/keys as a
> collection.  It is not natural to consider a number as a collection of other
> numbers.

No it's because it's natural to *iterate* over the keys of a dict.
It's also natural to iterate over the values of a key, or over the
key,value pairs, but general concensus changed recently to favor the
key side.  Quit a good thing I must say, for now it becomes so much
easier to do generic programming in Python, now that files, dicts,
sequences and what have you are unified in the way their iterating
ability is used.


>>
>> > said, I would find that the argument favors the use of range/xrange over
> the
>> > concept of iterable integers.
>>
>> I'm still concerned how it releates to `programming for everybody',
>> as that goal is a sure measure to keep Python lean and simple.
> I am not sure whether you are referring to iterable integers or range/xrange
> by the above.

sorry for the confusion, english is not my native language.
I still doubt that `for i in 5' is easily understood to mean what it's
supposed to mean under this PEP.  I don't have that reservation for
range, and i still think I would prefer an extended range that could
deal with iterable objects.

My change in position is only that I now think I *understand* the
proposal, not that I *like* it.  So Jim finally got me to the point
that for me it's a matter of preference:)


-- 
groetjes, carel



More information about the Python-list mailing list