> Not really. Available time is finite, and this isn't at the top of the list > of things I'd like to see (resuming the discussion of generators + > coroutines + iteration protocol comes to mind first). OK, get going on that one then! > >> Cool! Can we resist adding > >> > >> if key:value in dict > >> > >> for "parallelism"? (I know I can ...) > > > That's easy to resist because, unlike ``for key:value in dict'', it's > > not unambiguous: > > But > > if (key:value) in dict > > is. Just trying to help whoever *does* want the PEP <wink>. OK, I'll pronounce -1 on this one. It looks ugly to me -- too reminiscent of C's if (...) required parentheses. Also it suggests that (key:value) is a new tuple notation that might be useful in other contexts -- which it's not. > > ... > > I'm certainly more comfortable with just ``for key in dict'' than with > > the whole slow of extensions using colons. > > What about just the > > for key:value in dict > for index:value in sequence > > extensions? I'm not against these -- I'd say +0.5. > The degenerate forms (omitting x or y or both in x:y) are > mechanical variations so are likely to get raised. For those, +0.2. > > But, again, that's for the PEP to fight over. > > PEPs are easier if you Pronounce on things you hate early so that those can > get recorded in the "BDFL Pronouncements" section without further ado. At your service -- see above. --Guido van Rossum (home page: http://www.python.org/~guido/)
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