Tim Peters wrote: > > ... > > But if you add seq.items(), you had better add seq.keys() too, and > seq.values() as a synonym for seq[:]. I guess the perceived advantage of > adding seq.items() is that it supplies yet another incredibly slow and > convoluted way to get at the for-loop index? "Ah, that's the ticket! Let's > allocate gazillabytes of storage and compute all the indexes into a massive > data structure up front, and then we can use the loop index that's already > sitting there for free anyway to index into that and get back a redundant > copy of itself!" <wink>. > > not-a-good-sign-when-common-sense-is-offended-ly y'rs - tim .items(), .keys(), .values() and range() all offended my common sense when I started using Python in the first place. I got over it. I really don't see this "indexing" issue to be common enough either for special syntax OR to worry alot about efficiency. Nobody is forcing anyone to use .items(). If you want a more efficient way to do it, it's available (just not as syntactically beautifu -- same as range/xrangel). That isn't the case for dictionary .items(), .keys() and .values(). Also, if .keys() returns a range object then theoretically the interpreter could recognize that it is looping over a range and optimize it at runtime. That's an alternate approach to optimizing range literals through new byte-codes. I don't have time to think about what that would entail right now.... :( -- Paul Prescod - Not encumbered by corporate consensus Simplicity does not precede complexity, but follows it. - http://www.cs.yale.edu/homes/perlis-alan/quotes.html
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