[Phillip] > Does this mean that the C#-style syntax has a chance if it's got a > __future__? :) I don't see how that would change the arguments against it. > Also, you might want to define "superior" in order to avoid > re-opening the floodgates of syntax argument. No, but I suggest that the proponents of syntax alternatives will have to agree amongst themselves on a single alternative that they can present to me. > With regard to the PEP, I thought there were two volunteers who > mentioned an intent to work on it in the past week; if they are not > still doing so, I'd be happy to at least add the issues with "def > decorator functionname()" that I remember (visual confusion for > decorators w/arguments, tool confusion for existing tools). Please do (or coordinate with Skip who seems to have attracted this volunteer position). [Michael] > Do you want justifications, too? :-) That's up to you. :-) > I would beg of you to not give the idea that you or anyone else is > going to be counting votes on this at some point. Python is not a democracy. I can't be swayed by votes, only by good arguments. --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