[Python-Dev] Iterators (PEP 234)

[Christian Tismer]

"M.-A. Lemburg" wrote:
> 
> Christian Tismer wrote:
> >
> > "M.-A. Lemburg" wrote:
> > >
> > > Tuples are well-known basic Python types. Why should
> > > (key,value) be any harder to understand than key:value.
> > > What would you tell a newbie that writes:
> > >
> > > for key:value in sequence:
> > >     ....
> > >
> > > where sequence is a list of tuples and finds that this doesn't
> > > work ?
> >
> > Sorry about sneaking in. I do in fact think that the syntax
> > addition of key:value is easier to understand. Beginners
> > know the { key:value } syntax, so this is just natural.
> > Givin him an error in your above example is a step to clarity,
> > avoiding hard to find errors if somebody has a list of
> > tuples and the above happens to work somehow, although he
> > forgot to use .xitems().
> 
> The problem is that key:value in sequence has a meaning under PEP234:
> key is the current index, value the tuple.

Why is this a problem? It is just fine.

> > > Besides, the items() method has been around for ages, so switching
> > > from .items() to .xitems() in programs will be just as easy as
> > > switching from range() to xrange().
> >
> > It has been around for years, but key:value might be better.
> > A little faster for sure since we don't build extra tuples.
> 
> Small tuples are cheap and kept on the free list. I don't even
> think that key:value can do without them.

a) I don't see a point to tell me about Python's implementation
but for hair-splitting. Speed is not the point, it will just be
faster. b) I think it can.
But the point is the cleaner syntax which unambigously gets
you keys and values, whenether the thing on the right can be indexed.

> Anyway, I've already said that I'm -0 on these thingies -- I would
> be +1 if Ping were to make key:value full flavoured associations
> (Jim Fulton has written a lot about these some years ago; I think
> they originated from SmallTalk).

I didn't read that yet. Would it contradict Ping's version or
could it be extended laer?

...
> > Having to force every "iterable" object to support a modified
> > view of it via xitems() even doesn't look elegant to me.
> > It forces key/value pairs to go through tupleization only
> > for syntactical reasons. A weakness, not a strength.
> > Object orientation gets at its limits here. If access to keys
> > and values can be provided by a single implementation for
> > all affected objects without adding new methods, this suggests
> > to me that it is right to do so.
> 
> Hey, tuples are created for *every* function call, even C calls
> -- you can't be serious about getting much of a gain here ;-)

You are reducing my arguments to speed always, not me.
I don't care about a tuple. But I think we can save
code. Smaller *and* not slower is what I like.

no offence - ly y'rs - chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com