Christian Tismer wrote: > > "M.-A. Lemburg" wrote: > > > > 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. I'm not telling you (I know you know ;), but others on this list which may not be aware of this fact. > 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? Ping's version would hide this detail under the cover: dictionaries would sort of implement the sequence protocol and then return associations. I don't think this is much of a problem though. > ... > > > 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. At the cost of: * special casing the for-loop implementation for sequences, mappings * adding half a dozen new slots and methods * moving all the complicated details into the for-loop implementation instead of keeping them in separate modules or object specific implementations Perhaps we are just discussing the wrong things: I believe that Ping's PEP could easily be implemented on top of my idea (or vice-versa depending on how you look at it) of how the iteration interface should look like. -- 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