Pete> I'm sure others will come to me as soon as I hit send. I don't Pete> know if I get a vote, but I'm +2 on PEP 318. I'm +1 on the idea though with the post-arglist list-y syntax: def funct(a1, a2) [d1, d2]: pass for the same reasons Barry elaborated yesterday. The list constructor allows you to split across lines and the decorators are in some sense secondary to the function name and arguments which deserve to be displayed more prominently. Using (...) provides too little visual distinction with the function's argument list. Using <...> is tough for syntax highlighting editors because < and > are already relational operators and shouldn't visually balance in that context. Using {...} implies use of a dictionary, which in turn implies unordered application of multiple decorators. Not using any sort of bracket forces the use of backslashes to continue the decorator list across lines. Using "as" with or without any other syntactic sugar just seems like keyword noise to me. It's not necessary for the parser to disambiguate things and doesn't add much to the comprehension of the construct. If Guido is determined to add some English there we might as well go whole hog: def funct(a1, a2) modified by [d1, d2, wink(0.5)]: pass Skip
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