> At 10:14 AM 8/5/04 -0700, Guido van Rossum wrote: > >[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. > > I thought the primary argument against it was that it changes the meaning > of (potentially existing) Python code, and that you had rejected the "hard > to learn" argument on the basis that people learn by pattern-matching > rather than principle. No, the reason I decided to drop that was was the ambiguity in people's heads. > I guess this is another reason to update the PEP... :) Indeed. > >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. > > I think that will pretty much guarantee that it's either @ or > nothing: it appears that the two biggest (or at least most vocal) > camps are: > > 1. people who want a "simpler" syntax that doesn't support arguments (who > seem to mostly favor 'def classmethod foo()') Tough beans. They should have a look at how decorators are used in C# and Java 1.5. > 2. people who think that decorators without arguments are pointless, and > don't agree amongst themselves on the proper syntax, but don't necessarily > care that much as long as there *is* one. (But there may be a slight > leaning towards either of the C#-inspired variants.) So they should defend @ because it's there. --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