[Tim] > 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>. [Peter Schneider-Kamp]] > That's a -1, right? <0.1 wink> -0 if you also add .keys() and .values() (if you're going to hypergeneralize, don't go partway nuts -- then it's both more general than it should be yet still not as general as people will expect). -1 if it's *just* seq.items(). +1 on an "indexing" clause (the BDFL liked that enough to implement it a few years ago, but it didn't go in then because he found some random putz who had used "indexing" as a vrbl name; but if doesn't need to be a keyword, even that lame (ask Just <wink>) objection goes away). sqrt(-1) on Barry's generator tease, because that's an imaginary proposal at this stage of the game.
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