[Python-Dev] Call for defense of @decorators (original) (raw)
Phillip J. Eby pje at telecommunity.com
Thu Aug 5 20:41:38 CEST 2004
- Previous message: [Python-Dev] Call for defense of @decorators
- Next message: [Python-Dev] Call for defense of @decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
I guess this is another reason to update the PEP... :)
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:
people who want a "simpler" syntax that doesn't support arguments (who seem to mostly favor 'def classmethod foo()')
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.)
Personally, I think the C# list-before-function syntax is, on balance, the best of all the choices explored throughout the whole tangled history of PEP 318. It's visually attractive, doesn't break the parsing of existing tools (that may see '@' as a syntax error), and doesn't interfere with grepping for functions. The "learning" argument was done to death before you even invented the syntax: any decorator choice results in having to learn something.
Of course, I suppose that nearly all of these can be turned into opposite arguments, for example that '@' causing breakage is a good thing, because it means you'll get an error sooner (e.g. if you run the program under an older Python). And round and round the argument goes. And every so often, somebody invents a new syntax, for example:
foo = classmethod(
def foo(cls):
return 42
)
and then some people love it, and some hate it, and there we go back on the merry-go-round. Sigh. Just Pronounce on something and put us all out of your misery already. :)
- Previous message: [Python-Dev] Call for defense of @decorators
- Next message: [Python-Dev] Call for defense of @decorators
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]