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.
> > 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.
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 am -0 on the key:value thingie. If you want it as a way to
> > construct or split associations, fine. But it is really not
> > necessary to be able to iterate over dictionaries.
> >
> > > 3. Furthermore, this still doesn't solve the backward-compatibility
> > > problem that PEP 234 takes great care to address! If you write
> > > your for-loops
> > >
> > > for (key, value) in dict.xitems():
> > >
> > > then you are screwed if you try to replace dict with any kind of
> > > user-implemented dictionary-like replacement (since you'd have to
> > > go back and implement the xitems() method on everything).
> >
> > Why is that ? You'd just have to add .xitems() to UserDict and
> > be done with it. This is how we have added new dictionary methods
> > all along. I don't see your point here.
>
> You really wouldn't stick with UserDict, but implement this
> on every object for speed.
> The key:value proposal is not only stronger through its extra
> syntactical strength, it is also smaller in code-size to implement.
...but it's a special case which we don't really need and
it *only* works for mappings and then only if the mapping supports
the new slots and methods required by PEP234.
I don't buy the argument that PEP234 buys us fast iteration for
free. Programmers will still have to write the code to implement
the new slots and methods.
> 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 ;-)
--
Marc-Andre Lemburg
______________________________________________________________________
Company: http://www.egenix.com/
Consulting: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4