Except that what you show is currently valid syntax. Making a currently valid syntax mean something new is, I believe, generally frowned upon.

Not in this case. I've thought this through and don't think I see any practical issues with this syntax. --Guido van Rossum (home page: http://www.python.org/~guido/)

At 01:21 PM 3/30/04 -0800, Guido van Rossum wrote:

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

--Guido van Rossum (home page: http://www.python.org/~guido/)

I showed this to a Python programmer at my office. He immediately asked if this: if foo: [decorator1] else: [decorator2] def func(arg,arg): ... was valid. He then further commented that it was strange to have a Python construct split across two lines, and inquired whether these variants: [decorator] def func(arg,arg): ... [decorator1, decorator2 ] def func(arg,arg): [decorator] \ def func(arg,arg): ... would be considered legal as well. I also showed him the implemented syntax of 'def func(args) [decorators]:', and he thought it seemed natural and Pythonic, and he suggested 'as' as another possible alternative. We also discussed the issue of evaluation order, and wondered if perhaps the decorator order in your latest syntax should be in reverse of the order used for decorators-at-the-end. His last comment was that he thought it seemed very Perlish to begin a Python statement with special symbols, that then modify the behavior of code on a subsequent line. Some of his questions also got me to wondering how the grammar would even handle the initial proposal, since it seems it would have to be phrased as "lists can have an optional 'NEWLINE function-definition' clause after them". Anyway, I think I could manage to live with this syntax, although I really don't like it either, for many of the same reasons. I don't think that putting decorators at the end of the definition impedes visibility unless there are a really large number of arguments or a large amount of decorator data. In both cases, you're going to need to be reading more carefully anyway. For the common cases, it's all going to be on one line anyway. Oh... one more thing... the new proposal brings back up (to a limited extent) the "what to look up" question, in a different form. More precisely, someone who has learned basic Python syntax may wonder why somebody is creating a list with 'classmethod' in it, but unless they already know about the syntax rule, they have no way to even *guess* that it has something to do with the function definition that follows. By contrast, the decorators-last syntax is visibly part of the 'def' statement and gives much more clue as to its purpose.

The most obvious issues I see with this is are that: - grepping for "def func" won't show any sign that its decorated, and

Seems rather minor -- there's only so much you can cram on a single line.

- it looks like normal syntax, so it looks like expressions should work, e.g.

[decorator1] + [decorator2] def func(arg, arg):

or even:

get_std_decorators() # Returns a list def func(arg, arg):

I'm pretty sure this isn't the intention, though. I can imagine some posts to comp.lang.python asking how to do the above...

The same syntactic restrictions apply to docstrings (you can't have an expression of type string in the docstring position, it *has* to be a literal). Nobody's confused by that one.

Neither of these are fatal flaws, but I think I still prefer:

def func(args) [decorator]:

Which hides 'classmethod' behind the more voluminous stuff, and that's my main gripe. My main reasoning is as follows: 1) If we do decorators at all, decorators should be allowed to be arbitrary expressions. 2) Since we allow arbitrary expressions, decorators provide a much better way to set function attributes than the current way. 3) This will be attractive (better than putting special mark-up in docstrings), so there will be lots of voluminous decorators. 4) Then the "important" decorators like classmethod will be hidden at the end of the list of decorators. The [...] prefix proposal addresses this by putting the end of the decorator list closest to the def keyword. This doesn't look so bad: [funcattr(spark="<spark syntax here>", deprecated=True, overrides=True), classmethod] def foo(cls, arg1, arg2): pass --Guido van Rossum (home page: http://www.python.org/~guido/)

Hm. So if we reversed the order so that the outermost decorators (such as classmethod) come first in the list, would that sway you to relent in favor of decorators-after-arguments?

Not really, because they're still hidden behind the argument list.

I don't like the reversed order, but I think I'd be a lot more comfortable with explaining that relatively minor semantic oddity to other developers than I would be with trying to explain the major syntactic oddity (relative to the rest of the Python language) of decorators-before-def.

OTOH to C# programmers you won't have to explain a thing, because that's what C# already does. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

...

Hm. So if we reversed the order so that the outermost decorators (such as classmethod) come first in the list, would that sway you to relent in favor of decorators-after-arguments?

Not really, because they're still hidden behind the argument list.

Because:

1) it won't be on the same line if there are lots of arguments 2) nobody will read past the argument list 3) other 4) all of the above 5) none of the above

(Not trying to change your opinion; I just think the answer to this should go in the PEP.)

1&2, mostly.

...

...

I don't like the reversed order, but I think I'd be a lot more comfortable with explaining that relatively minor semantic oddity to other developers than I would be with trying to explain the major syntactic oddity (relative to the rest of the Python language) of decorators-before-def.

OTOH to C# programmers you won't have to explain a thing, because that's what C# already does.

Correct me if I'm wrong, but I don't believe C# attributes have anything like the same semantics as Python decorators; in fact I believe they may be more akin to Python function attributes! So, even to a C# programmer, I'll have to explain Python's semantics.

Yes of course, but the basic idea that this specifies attributes should be clear to them. You always have to explain Python's semantics -- even assignment is deeply different!

Indeed, the C# syntax has things like this:

[ReturnValue: whatever(something)]

to specify what the attributes apply to, and they can be applied to parameters, the return value, the module as a whole, etc. But I don't want to get too far off-topic.

By the way, you didn't mention whether it's okay to put the decorators on the same logical line, e.g.:

[classmethod] def foo(bar,baz): # body goes here

If the rationale here is that we're copying C#, I'd think that it should be permissible, even though it looks a bit ugly and tempts me to indent the body to align with the function name.

This is much harder to do with the current parser. (My plan would be to tie the list expression and the function definition together in the code generating phase, just like doc strings.) --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, Mar 31, 2004 at 12:32:35PM -0500, Phillip J. Eby wrote:

I personally would rather have the decorators required to be on the same logical line, and then use:

[classmethod] \ def foo(bar,baz): pass

for visual separation. The backslash visually alerts that this is *not* a mere bare list.

I agree with Phillip about the backslash. But I don't like this variant because it appears to operate by side-effect. If the list had a keyword after it, that wouldn't be as bad, but the only current keywords I can think of (in, for) don't fit well and would overload their meaning. I don't really like any variants, but the original seems the least bad to me: def foo(bar, baz) [classmethod]: Some of the concerns deal with the decorators getting lost after the arguments or they are too far away from the function name. It seems to me that if formatted properly, this isn't as big of a deal: def foo(cls, lots, of, arguments, that, will, not, fit, on, a, single, line) \ [classmethod, decorate(author='Someone', version='1.2.3', other='param')]: """The docstring goes here.""" I hope that's a pretty unrealistic case. I think all of the proposed variants are ugly with the definition above. But, this may be more reasonable: def foo(cls, lots, of, arguments, all, on, a line) \ [classmethod, decorate(author='Someone', version='1.2.3', other='param')]: """The docstring goes here.""" Writing decorators this way is the least surprising to me. Although, I wish there was a better alternative. Neal

There appears to be a strong correlation between people who have specific use cases for decorators, and the people who want the last-before-colon syntax. Whereas, people who have few use cases (or don't like decorators at all) appear to favor syntaxes that move decorators earlier. Whether that means the "earlier" syntaxes are better or worse, I don't know. <0.5 wink>

Maybe the practitioners are so eager to have something usable that they aren't swayed as much by esthetics.

I'll assume your intent is to prevent decorators from biting the unwary -- specifically people who *don't* use decorators a lot and therefore are not looking for them. I will therefore focus now on the issues with the "previous line" syntax that may bite people, with an eye to how they might be fixed.

They should still be very unlikely to accidentally create one. With proper vertical whitespace, the fact that a decorator list (written properly) means something special should be obvious to even the most casual observer: there should be a blank line before the decorator list and none between it and the 'def' line. The human brain is a lot more flexible in picking up patterns than the Python parser; as shown many times in this discussion, most people have no clue about the actual syntax accepted by the Python parser, and simply copy (and generalize!) patterns they see in examples. My goal is to help people grasp the gist of a particular construct without having to think too much about the exact syntax; within all sorts of other constraints of course, like being parsable with the simple ans stupid LL(1) parser, and being easy to grep (in some cases).

...

...

By the way, you didn't mention whether it's okay to put the decorators on the same logical line, e.g.:

[classmethod] def foo(bar,baz): # body goes here

If the rationale here is that we're copying C#, I'd think that it should be permissible, even though it looks a bit ugly and tempts me to indent the body to align with the function name.

This is much harder to do with the current parser. (My plan would be to tie the list expression and the function definition together in the code generating phase, just like doc strings.)

Yeah, this is also going to now have to be a special case for documentation processing tools.

I hadn't thought of those, but the new situation can't be worse than before (decorations following the 'def'). Usually these tools either use some ad-hoc regex-based parsing, which shouldn't have any problems picking out at least the typical forms, or they (hopefully) use the AST produced by the compiler package -- it should be possible for that package to modify the parse tree so that decorators appear as part of the Function node.

Whereas making it part of the definition syntax, it's more directly available in the parse tree.

Definitely, but I don't see it as a showstopper. I've now implemented this for the traditional compile.c; I think the effort is fairly moderate. (My patch is smaller than Michael Hudson's.)

It also seems to be working against the AST branch a bit, in that I would expect the decorator expressions to be part of the function definition node, rather than in an unrelated statement. And, it's also going to be interesting to document in the language reference, since the grammar there is going to continue to diverge from the "real" grammar used by the implementation.

Hardly worse than the difference between theory and practice for assignment statements or keyword parameters.

Another issue... is this valid?

[classmethod]

def foo(bar,baz): pass

Yes.

How about this?

[classmethod] # Okay, now we're going to define something... def foo(bar,baz): pass

Yes.

If they *are* valid, then you can have nasty effects at a distance.

Given that there really isn't much of a use case for putting a list display on a line by itself (without assigning it to something), I don't see this as a likely accident. By giving only sane examples we'll help people write readable code (I see no other way; you can't force people to write unobfuscated code :-).

If they *aren't* valid, accidentally adding or removing whitespace or comments can silently change the meaning of the program, and *not* in a DWIMish way.

I personally would rather have the decorators required to be on the same logical line, and then use:

[classmethod] \ def foo(bar,baz): pass

for visual separation. The backslash visually alerts that this is *not* a mere bare list.

Ugly, and the stupid LL(1) parser can't parse that -- it needs a unique initial symbol for each alternative at a particular point.

I'm not a parser guru by any stretch of the imagination, but wouldn't it be possible to simply create a statement-level construct that was something like:

liststmt: '[' [listmaker] ']' ( funcdef | restofliststmt )

and put it where it matches sooner than the expression-based versions of the statement?

Maybe in SPARK, but not in Python's LL(1) parser.

It seems like the main complexity would be the possibility of having to duplicate a number of levels of containing rules for 'restofliststmt'. But maybe I'm completely off base here and there's no sensible way to define a correct 'restofliststmt'.

You can assume that's the case. :) --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2004-03-31 at 16:12, Phillip J. Eby wrote:

At 12:49 PM 3/31/04 -0800, Guido van Rossum wrote:

...

I hadn't thought of those, but the new situation can't be worse than before (decorations following the 'def'). Usually these tools either use some ad-hoc regex-based parsing, which shouldn't have any problems picking out at least the typical forms, or they (hopefully) use the AST produced by the compiler package -- it should be possible for that package to modify the parse tree so that decorators appear as part of the Function node.

Good point. Will this be true for the AST branch's AST model as well?

If decorators get added, that's my plan. Jeremy

I think most of the worry about long, complicated decorator lists with baroque parameters is FUD. What are the realistic use cases for such things? I don't remember seeing any proposed. The ones I have seen proposed (e.g. PyObjC) use only one or two decorators at a time, and if there are any parameters, they're not lengthly. Furthermore, if in some circumstance someone finds themselves writing decorator lists so long that they become unreadable, well, there are ways of dealing with that. For example, foo_decorators = decorator_list( # Big long-winded # list of # decorators ) def foo(args) [foo_decorators]: ... which is not much different from Guido's preceding-list version, with the advantage that it's explicit about the fact that you need to look above to get the full picture. Please let's not allow unfounded speculation to get in the way of coming up with a nice syntax that works well in the majority of cases we expect to actually see. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

Another thought about: [decorator] def foo(args): ... What are newcomers going to make of this? It looks like a thrown-away list followed by a def, and there's no clue that there's any connection between the two. And even if the newcomer suspects that there is some kind of connection, what are they going to look up in the manual? At least with def foo(args) [decorator]: ... it's clear that (1) something different is going on, and (2) it's somehow a part of the 'def' statement. Everywhere else in Python where you can say something someotherthing it means "do something and then do someotherthing", and the combined result can be deduced from knowing what something and someotherthing each do on their own. This breaks that. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

On Thu, 2004-04-01 at 23:28, Jeremy Hylton wrote:

On Thu, 2004-04-01 at 22:34, Greg Ewing wrote:

...

Another thought about:

[decorator] def foo(args): ...

What are newcomers going to make of this?

It looks like a thrown-away list followed by a def, and there's no clue that there's any connection between the two.

I think it's obvious that there's a connection between the two. A bare list by itself would be nonsense and the actual list would probably say something like [classmethod] which suggests it's saying something about a method.

It may be nonsense, but it means something today. So it can't be obvious that they're connected because today, they aren't. If tomorrow this same code means something different, users looking at the code will have to know what version of Python they're using, and make sure it's the right one ("uh, how do I do that?"). If they were to use decorator-before-def code in an older version of Python, the program would be accepted but silently do the wrong thing. At least with decorator-before-colon trying to run the code in older interpreters will barf loudly. -Barry

Barry Warsaw writes:

At least with decorator-before-colon trying to run the code in older interpreters will barf loudly.

On Friday 02 April 2004 11:34 am, Michael Hudson wrote:

I think this is a good point that hadn't occurred to me: silent failures suck.

There's also the little matter that using syntax only, without new keywords, allows us to avoid __future__ imports and all the implementation cruft that entails. Decorator-before-colon wins out big time for me. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

Michael Hudson writes:

Barry Warsaw writes:

...

If tomorrow this same code means something different, users looking at the code will have to know what version of Python they're using, and make sure it's the right one ("uh, how do I do that?"). If they were to use decorator-before-def code in an older version of Python, the program would be accepted but silently do the wrong thing.

At least with decorator-before-colon trying to run the code in older interpreters will barf loudly.

I think this is a good point that hadn't occurred to me: silent failures suck.

Wouldn't the decorator-before-def require a 'from __future__ import decorators' (Although I'm still on favor of the decorator-before-colon version)? Thomas

On Fri, 2004-04-02 at 12:05, Jeremy Hylton wrote:

On Fri, 2004-04-02 at 08:24, Barry Warsaw wrote:

...

It may be nonsense, but it means something today. So it can't be obvious that they're connected because today, they aren't.

Your original complaint was: "What are newcomers going to make of this?" Newcomers aren't going to be worried about the small change in semantics that decorator-before would entail, because they won't know the old semantics.

They already know the old semantics. If they were to encounter that syntax today, they'd know that Python throws away the results. If /I/ saw that construct in today's Python code, I'd start looking for side effects.

...

If tomorrow this same code means something different, users looking at the code will have to know what version of Python they're using, and make sure it's the right one ("uh, how do I do that?"). If they were to use decorator-before-def code in an older version of Python, the program would be accepted but silently do the wrong thing.

I agree there's a risk here, but we've faced that kind of risk before. We used future statements for nested scopes, but only one version. If you're looking at code with free variables, you need to know whether it was written to run with or without nested scopes. Code written for one version will fail at runtime on the other. (It may or may not fail silently.)

Adding a future statement would make decorator-before-def slightly more acceptable. Adding a keyword to introduce decorator-before-def would make it slightly more acceptable. All-in-all, I still think decorator-before-colon is plenty readable and the more obvious of the two choices. -Barry

Guido van Rossum wrote:

While I ponder the decorator syntax, let's propose some built-in decorators.

We've already got classmethod and staticmethod.

I propose this one to set function attributes:

class func_attrs(objects):

def __init__(self, **kwds): self.attrs = kwds

def __call__(self, funcobj): funcobj.__dict__.update(self.attrs)

Did you leave out the 'return funcobj' from the end of __call__? I thought that decorators were supposed to be inherently cooperative, and should return their modified funcobj, or a new func-like-obj. Or maybe I haven't been paying close enough attention... -Kevin

Guido van Rossum wrote:

...

...

class func_attrs(objects):

def __init__(self, **kwds): self.attrs = kwds

def __call__(self, funcobj): funcobj.__dict__.update(self.attrs)

Did you leave out the 'return funcobj' from the end of __call__? I thought that decorators were supposed to be inherently cooperative, and should return their modified funcobj, or a new func-like-obj.

Sorry, you're right. (I've been thinking of interpreting a None result as "keep the input object" but the code generation would be too messy.

Cool. And now that I have my pedantic hat on, I may as well go all out. First, why call it func_attrs, when staticmethod and classmethod are underscoreless? Second, I know it is effectively the same, but shouldn't the .update line use vars(funcobj) instead of funcobj.__dict__? This is something that I am asked (often!) by my Python students. I use vars(obj) since it looks less magical. -Kevin

On Fri, 2004-04-02 at 15:32, Guido van Rossum wrote:

We had a discussion about naming conventions recently, and I believe the outcome was that most folks like underscores in their names. OTOH if I was writing this just for *me*, I would indeed make them underscoreless.

Actually, for multi-word method and function names, we preferred underscores to camelCasing. But I still wish has_key() were haskey() and since neither "func" nor "attr" are actual words, funcattrs() is just fine. :) I'm torn on whether new decorators should go in as built-ins or not. It's darn convenient to stick them there, but I worry that the documentation for the builtin module is getting pretty hefty now (and no, I really don't want to do something like an os module split -- man, I hate those pages ;). -Barry

[Guido]

... doctest_script(multi_line_string) -- specifies a doctest script, for use by the doctest module (if this is absent, it will continue to look in the doc string). I like to separate the doctest script from the actual documentation string because, when used for rigorous unit testing (as in Jim&Tim's talk at PyCON), the doctest script is too long to double as reasonable documentation. Maybe this should be imported from the doctest module.

Let me try to squash this one before it gains traction from people who don't use doctest anyway <wink>. Burying a large triple-quoted string inside a function call inside an indented "list" isn't going to help the readability of anything. Zope use is moving toward putting large doctests into their own .py file, or, more recently, into their own .txt file. An example of the former: http://cvs.zope.org/ZODB/src/ZODB/tests/testmvcc.py The idea that "too long" makes for unreasonable documentation doesn't make sense to me: these long doctests read like tutorials liberally sprinkled with Python examples, and are the best docs some of these subsystems will ever have. Indeed, the Python Tutorial is a prime example of something that "should be" a doctest, and I think that's exceptionally good documentation. Of course this doesn't preclude putting a judiciously few examples in docstrings either (also for doctest chewing), but I'd rather encourage people who want more than that to go all the way, and write a tutorial-style large doctest in its own file.

Guido van Rossum writes:

While I ponder the decorator syntax, let's propose some built-in decorators.

[...]

We could also add a standard implementation of synchronized. Or perhaps that should be imported from threading. (But is that really a good thing to copy from Java?)

I don't want to sound FUDdy, but I was under the impression that people didn't think this is something we actually want...

Other possibilities (all these are pretty much thinking aloud and very much up for votes; and not original, I've seen these proposed before!):

[...]

overrides -- indicates that this overrides a base class method. Maybe the default metaclass could check that if this is used there actually is a corresponding base class method, and we might have a "strict" metaclass that checks this is set for all overriding methods.

I don't get the point of this.

I'm still torn whether to promote defining properties this way:

[propget] def x(self): "Doc string for x" return self.__x

[propset] def x(self, newx): self.__x = newx

[propdel] def x(self): del self.__x

but if people like this (whatever the decorator syntax :) we might as well make this the recommended way to define properties.

- "a bit" I'm not sure I like the idea of promoting something that uses sys._getframe.

Should there be a a separate module from which all those decorators are imported, or should we make them built-ins, following the trend set by classmethod etc.?

I'm not sure any of the above are important enough to be builtins. funcattrs, maybe, but there's sod all reason to implement that in C, and getting Python implementations into the builtins seems likely to be pain. Could do it in site.py, I guess. Cheers, mwh -- Also, remember to put the galaxy back when you've finished, or an angry mob of astronomers will come round and kneecap you with a small telescope for littering. -- Simon Tatham, ucam.chat, from Owen Dunn's review of the year

At 09:07 AM 4/3/04 -0800, Guido van Rossum wrote:

...

...

We could also add a standard implementation of synchronized. Or perhaps that should be imported from threading. (But is that really a good thing to copy from Java?)

I don't want to sound FUDdy, but I was under the impression that people didn't think this is something we actually want...

Hence my parenthetical remark.

But given that it is quite simple to do using decorators, surely *someone* will implement it. How useful it will be remains to be seen. Maybe someone should take this idea, run with it, and report how it enhanced their project?

For what it's worth, Jim Fulton's ExtensionClass package has had a "synchronized" metaclass implemented in C since about... 1997? I don't know of anybody actually using it, though. For my few dabblings into objects being shared across threads, though, I've typically needed rather precise control over when things get locked and unlocked and how, so I've never bothered implementing a synchronizing decorator.

At 06:15 PM 4/3/04 +0200, Martin v. Löwis wrote:

Guido van Rossum wrote:

...

I'm still torn whether to promote defining properties this way: [propget] def x(self): "Doc string for x" return self.__x [propset] def x(self, newx): self.__x = newx [propdel] def x(self): del self.__x but if people like this (whatever the decorator syntax :) we might as well make this the recommended way to define properties.

Does that actually work? I.e. is there an implementation of propget, propset, propdel so that this code introduces a property x?

Yes, using sys._getframe().f_locals[function.func_name]. Someone posted a link to an implementation earlier this week.

My understanding is that above syntax would be short for> [propget] def x(self): "Doc string for x" return self.__x x = propget(x)

def x(self, newx): self.__x = newx x = propset(x)

def x(self): del self.__x x = propdel(x)

Later assignments to x would override earlier ones, so that only the propdel survives.

Technically, what you show is not the actual expansion of the new syntax. The new syntax applies decorators before binding 'x' to the new function. So, the old value of 'x' is available to a decorator via sys._getframe().f_locals. This technique is also useful for implementing generic functions and/or multimethods, signature-based overloading, etc.

How would this be interpreted?

x = 42

def x(self) [propget]: "Doc string for x" return self.__x

def x(self, newx) [propset]: self.__x = newx

def x(self) [propdel]: del self.__x

That is, there is already an (otherwise invalid) 'x' in the calling scope when propget() is called. Do the property doodads just need to be bulletproofed or should an exception be raised?

It's broken. I expect this to raise an exception at some point. Beyond that, who cares? --Guido van Rossum (home page: http://www.python.org/~guido/)

...

I'm still torn whether to promote defining properties this way:

[propget] def x(self): "Doc string for x" return self.__x

[propset] def x(self, newx): self.__x = newx

[propdel] def x(self): del self.__x

but if people like this (whatever the decorator syntax :) we might as well make this the recommended way to define properties.

Does that actually work? I.e. is there an implementation of propget, propset, propdel so that this code introduces a property x?

Yes, but it involves sys._getframe().

My understanding is that above syntax would be short for> [propget] def x(self): "Doc string for x" return self.__x x = propget(x)

def x(self, newx): self.__x = newx x = propset(x)

def x(self): del self.__x x = propdel(x)

Later assignments to x would override earlier ones, so that only the propdel survives.

No, the semantics of decorators are that the function name isn't actually assigned to for the first time until all decorators have been called. So the previous binding of that name is available to devious decorators like these. (This wasn't my idea -- someone else proposed it here first. :) --Guido van Rossum (home page: http://www.python.org/~guido/)

"Guido van Rossum" wrote in message news:200403302121.i2ULLIM09840@guido.python.org...

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

Taking the prefix position as given for the moment, why overload list literal syntax versus something currently illegal and meaningless? Such as [[decorator]] # easy enough to type, or <decorator> # almost as easy, or <<decorator>> Is there near precedent in other languages that I don't know of? Regardless of syntax, the way I would think of the process (ie, 'come to terms with it') is this: a string literal immediately after a function heading automagically sets the special __doc__ attribute. A list literal (if that is what is used) automagically set a special __postprocess__ attribute which is read once after the body is compiled and deleted when no longer needed. As I understand the proposal, the actual storage would be elsewhere in the interpreter, so the above would be 'as if'. But, would it be useful for later introspection to actual set and leave such an attribute that records the decorator processing of the function? Terry J. Reedy

...

Taking the prefix position as given for the moment, why overload list literal syntax versus something currently illegal and meaningless? Such as

<decorator> # almost as easy, or

Yes. This looks better and will make it more clear that it's a special case. Otherwise the decorators will look too decoupled from the function.

Why does <...> look better than [...]? To me, <...> just reminds me of XML, which is totally the wrong association. There are several parsing problems with <...>: the lexer doesn't see < and > as matched brackets, so you won't be able to break lines without using a backslash, and the closing > is ambiguous -- it might be a comparison operator. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

...

Why does <...> look better than [...]? To me, <...> just reminds me of XML, which is totally the wrong association.

I vote for << >>. The brackets and parens have too many meanings in Python already. <> looks more like French than XML. ;) Paul Prescod

On 2004-04-01, at 01.32, Guido van Rossum wrote:

...

...

Why does <...> look better than [...]? To me, <...> just reminds me of XML, which is totally the wrong association.

I vote for << >>. The brackets and parens have too many meanings in Python already. <> looks more like French than XML. ;)

<<...>> has the same practical problems as <...>: no automatic line breaking, >> is ambiguous.

So is automatic line breaking really necessary? Why not just wrap the actual decorators inside parentheses if you need to? Like: <<(long_decorator(attrs={'author':'somebody', 'frequency':'daily'}), another_decorator, one_more_decorator)>> <(long_decorator(attr={'author':'somebody', 'frequency':'daily'}), another_decorator, one_more_decorator)> Well ... it's not pretty. As for the ambiguity: If '[...]' can be handled for that special case, can't '<...>' or '<<...>>' also be handled? They would be much less ambiguous for the human interpreter.

Anyhow, I just meant that if you find a pair of characters that are illegal today then many of the objections about abusing existing syntax would go away.

So how about *[...]* ? Or perhaps [*...*]? Or [|...|]? --Guido van Rossum (home page: http://www.python.org/~guido/)

On 2004-04-01, at 17.44, Guido van Rossum wrote:

...

Anyhow, I just meant that if you find a pair of characters that are illegal today then many of the objections about abusing existing syntax would go away.

So how about *[...]* ? Or perhaps [*...*]? Or [|...|]?

Also: Is it definite that it should be square brackets instead of parentheses? --- (sigh ... mail problems)

How about INDENT[...]:DEDENT? <0.5 serious>

Alas, won't work -- if the decoration is the first thing in a class body, you'd have something starting with double indent, but the lexer never gives you that. class C: [staticmethod] def foo(): pass This would be tokenized as 'class' 'C' ':' NEWLINE INDENT '[' 'staticmethod' ']' NEWLINE <ILLEGAL DEDENT> --Guido van Rossum (home page: http://www.python.org/~guido/)

At 21:52 30.03.2004 -0500, Terry Reedy wrote:

[[decorator]] # easy enough to type, or

this already just valid syntax today

<decorator> # almost as easy, or <<decorator>>

Is there near precedent in other languages that I don't know of?

VB.NET uses <...> for .NET attributes instead of [...]. OTOH <...> is a usual syntax for parametrized types, e.g. C++ templates, Java,C# generics and others It seems VB.NET will use a syntax with (...) for that.

[Ping]

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

[Guido]

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

+0. I'm not convinced that Python actually needs decorators, but if I were that would be a +1; I certainly like this spelling better than the other ones.

I've produced a patch for my version: python.org/sf/926860 This patch (deco.diff) patches compile.c to recognize the following form of decorators: [list_of_expressions] def func(args): ... The list of expressions should contain at least one element and should not be a list comprehension, otherwise no special treatment is taken. (An empty list has no effect either way.) There's a simple test suite, Lib/test/test_decorators.py. I don't expect to have time to discuss this until tonight. --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 2004-03-31 at 23:30, Greg Ewing wrote:

Guido:

...

This patch (deco.diff) patches compile.c to recognize the following form of decorators:

[list_of_expressions] def func(args): ...

I need a reality check here. Are you saying *this* is what you currently favour?

I hate this. It's unspeakably horrible. Please tell me I'm having a nightmare...

There's got to be a better way for people to share their preference on matters like these. Maybe we should create a Wiki page where people can sign up for or against any particular syntax. It would be easier to keep track of than trying to read all the messages in this thread. Jeremy PS Unspeakably horrible is a minor objection on the Internet. It's not really bad unless its untype-ably bad.

Guido van Rossum writes:

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

Seems like it would be painful to implement. Obviously that's not a killer blow, but: If the implementation is hard to explain, it's a bad idea. Cheers, mwh -- If design space weren't so vast, and the good solutions so small a portion of it, programming would be a lot easier. -- maney, comp.lang.python

On Tue, 2004-03-30 at 16:21, Guido van Rossum wrote:

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

I don't like it. It already has a meaning (albeit fairly useless) and it doesn't seem obvious from just looking at it that the decorator is connected to the following method. It doesn't taste Pythonic to me. -Barry

On Wed, Mar 31, 2004 at 10:41:00PM -0500, Barry Warsaw wrote:

On Tue, 2004-03-30 at 16:21, Guido van Rossum wrote:

...

...

Another possibility that has been suggested is

[decorator] def func(arg, arg):

And one that I currently favor. I'm out of bandwidth to participate on a msg-by-msg basis, but perhaps folks can see if they can come to terms with this solution?

I don't like it. It already has a meaning (albeit fairly useless) and it doesn't seem obvious from just looking at it that the decorator is connected to the following method. It doesn't taste Pythonic to me.

Me too, but no one contrasted my actual use cases with any in any other format, so I must be missing something fundamental. I support an all Guido ticket now and forever, but I don't get the pulling-the-rabbit-out-of-a-hat decorator syntax anymore than the at-sign assignment. Something in the water at PyCon? -jackdied

On Thu, 2004-04-01 at 08:43, Skip Montanaro wrote:

IN this case there are other practical proposals on the table, not the least of which is the status quo.

So I hacked up python-mode a bit to support the syntax coloring of Guido's previously MFS (most favored syntax). I wanted to see if the concerns about visual obscurity were real or not. Then I rewrote a few methods of mine that would benefit from decorators (with some elaboration). A screen shot of my XEmacs buffer is here: http://barry.warsaw.us/xemacs.png Now, I'm sure most of you will hate my color scheme, but I'm used to it so for me, the decorator stands out perfectly fine. I'd have no problem supporting decorator-before-colon and vastly prefer it to decorator-before-def. You can play with this yourself by checking out the latest version of python-mode.el (from sf.net/projects/python-mode). Note that you won't get the nice colorization on multiline decorators on the fly because XEmacs doesn't handle as-you-type font-locking across newlines well. Re-fontifying the buffer will pick up the right colors though. -Barry

Jeremy Hylton wrote:

Another possibility that has been suggested is [decorator] def func(arg, arg):

The decorator before def spelling is familiar from C#, and looks the nicest to me. However, I'm curious about the way decorators differ from docstrings to explain putting one kind of metadata shorthand before def and the other after. [decorator] def func(arg, arg): """Docstring""" pass def func(arg, arg): [decorator] """Docstring""" pass If there will only ever be two of these kinds of things, and a consensus is to put them on lines before and after the def, that would seem to be reason enough for decorator before def. If someday there were other types of metadata distinct from decorators, perhaps immutable and pertaining to secure execution, the before-docstring spelling might allow for more consistent additions to the shorthand. def func(arg, arg): [decorator] (otherator) """Docstring""" pass

If you spell decorators this way:

[decorator] def func(): pass

then what will happen when you type [decorator] at an interactive interpreter prompt?

...

...

...

[decorator]

Will it type ... and wait for you to say more? Or will it evaluate the single-element list whose element is the value of the variable ``decorator'' and print the result?

The latter. You can't add a decorator to a top-level function in interactive mode unless you put it inside an if. Check out the behavior of the patch I posted (926860). --Guido van Rossum (home page: http://www.python.org/~guido/)

On Wed, 31 Mar 2004, Guido van Rossum wrote:

...

...

...

...

[decorator]

Will it type ... and wait for you to say more? Or will it evaluate the single-element list whose element is the value of the variable ``decorator'' and print the result?

The latter. You can't add a decorator to a top-level function in interactive mode unless you put it inside an if.

This discussion is turning in a direction that alarms me. Guido, i beg you to reconsider. Up to this point, we've all been talking about aesthetics -- whether it's prettier to have the list of decorators here or there, reads more naturally, visually suits the semantics, and so on. Putting the [decorator] on a separate line before the function changes the stakes entirely. It sets aside real functional issues in favour of aesthetics. Being enamoured with the way this syntax *looks* does not justify functionally *breaking* other things in the implementation to achieve it. Consider the arguments in favour: 1. Decorators appear first. 2. Function signature and body remain an intact unit. 3. Decorators can be placed close to the function name. These are all aesthetic arguments: they boil down to "the appearance is more logical". Similar arguments have been made about the other proposals. Consider the arguments against: 1. Previously valid code has new semantics. 2. Parse tree doesn't reflect semantics. 3. Inconsistent interactive and non-interactive behaviour. [*] 4. Decorators can be arbitrarily far away from the function name. These are all functional arguments, with the exception of 4. People are pointing out that the way Python *works* will be compromised. Putting the [decorator] on a separate preceding line: 1. violates a fundamental rule of language evolution, 2. makes it impossible to write an unambiguous grammar for Python, and 3. stacks the odds against anyone trying to learn decorators. I don't think there is any dispute about functionality. Everyone agrees that the interactive interpreter should reflect non-interactive behaviour as much as possible; everyone agrees that previously valid code should not change semantics; everyone agrees that the parse tree should reflect the semantics. Your responses to these points have been of the form "Well, it's not *so* bad. Look, we can hack around it..." Those aren't positive arguments. Those are excuses. Aesthetic and functional arguments are at two entirely different scales. To persist in finding excuses for one option because it is subjectively good-looking, while setting aside objective functional deficiences, is outside the bounds of reason. Special cases aren't special enough to break the rules. Please, i implore you, consider a different option on this one. Thanks for reading, -- ?!ng [*] Please don't say "Oh, the interactive and non-interactive modes are inconsistent already." That's not a reason to make it worse. Having the interactive interpreter close an "if:" block when you enter a blank line doesn't make "if:" totally unusable. But interpreting decorators inconsistently fails in a way that the decorator doesn't work at all, and provides no hint as to how you would make it work. This is especially bad since decorators are a weird and wonderful feature and people are going to have to experiment with them in the interactive interpreter as part of the learning process. Every such inconsistency makes Python harder to learn, and in particular this will make decorators especially painful to learn.

On Wed, Mar 31, 2004, Ka-Ping Yee wrote:

Special cases aren't special enough to break the rules.

Please, i implore you, consider a different option on this one.

+1 -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ "usenet imitates usenet" --Darkhawk

At 01:23 PM 4/5/04 +1200, Greg Ewing wrote:

Ka-Ping Yee :

...

Putting the [decorator] on a separate line before the function changes the stakes entirely. It sets aside real functional issues in favour of aesthetics.

Not only that, but I think the aesthetics of this version are *worse* than anything that's been considered before. It strikes me as deeply wrong and un-Pythonic -- so much so that I can't understand why Guido is even considering it.

There are different kinds of aesthetics. Guido's proposal has grown on me from a *visual* aesthetics point of view. After I worked with it a little bit, I realized it really is much prettier than decorators-before-colon. However, from more intellectual aesthetics (consistency, predictability, etc.) I still dislike it, and don't really see how to sanely reconcile it with the Python syntax of today. I wish that I did, because it really does *look* better for simple decorators. On the other hand, *no* syntax proposed so far has been really that nice to look at when used for multiple decorators.

On Mon, 2004-04-05 at 05:33, Guido van Rossum wrote:

I, too, wish that there were a way to make it work with current expectations. The * prefix looks so arbitrary: why not /, why not @, etc...

What about: [as classmethod] def foo(bar, baz): pass To me this is more obvious (and less like p*rl) that *[classmethod], and it is also currently a syntax error so won't break existing code. Mark Russell

On Mon, 2004-04-05 at 11:38, David Abrahams wrote:

Not bad. Also tolerable:

as [classmethod] def foo(bar, baz): pass

The trouble with that is that its less clearly an error at the moment (e.g.: as = [ 'pathological' ] classmethod = 0 as [classmethod] def foo(bar, baz): pass is actually legal right now). The nice thing about "[as xxx]" is that there's no way you can confuse it with a subscript expression. Mark

On Monday 2004-04-05 at 15:42, Andrew Koenig wrote:

Here's what I don't understand.

I imagine that most of the time, when someone decorates a function with lots of attributes, there is at least the possibility of decorating more than one function with the same set of attributes.

In such a case, doesn't it make sense to bind a variable to the attributes and use it instead?

Attributes = [staticmethod, classmethod, otherattributes(debug=True)]

def foo(bar, baz) Attributes: pass

And doesn't this idea answer the objection that too many attributes after the parameter list make the definition hard to read?

It certainly answers that objection, but it has (so it seems to me) other problems of its own; see below.

For that matter, why do we need the brackets if there is only one attribute:

def foo(bar, baz) staticmethod: pass

I am suggesting that what comes between the ) and the : should be an expression, which must evaluate to either a callable or a sequence of callables. For that matter, why not allow a tuple expression without parentheses:

def foo(bar, baz) staticmethod, classmethod: pass

Whatever sequence you put there, I think the semantics are clear: Before binding a name to the function, pass it to the callable or in turn to each element of the sequence.

The brackets serve multiple purposes. - They make the decoration *look*, even to novice eyes, like an annotation: "by the way, please make this a static method". - They may possibly help the parser a little. (I'm showing my ignorance here; I haven't really looked at the Python parser at all.) - They give a hint to the user that what goes in between them may be a sequence, not just a single item. - They ensure that all decorated definitions have a somewhat consistent appearance. Omitting them breaks all these things, especially if an arbitrary expression is allowed there. And do we really want to allow def foo(bar, baz) quux(wibble, spong): pass That's not a hideous pathological case; it's what a simple decoration using a parameterized decorator will look like without the brackets. With good decorator names I suppose it becomes somewhat comprehensible: def foo(bar, baz) memoized(25): pass but surely it's still much clearer when written as def foo(bar, baz) [memoized(25)]: pass or even (though I'm a little tempted to agree with whoever it was that was wondering whether Guido has been abducted by aliens) [memoized(25)] def foo(bar, baz): pass We can keep the syntactic distinctiveness while still allowing multiple decorators to be combined, by having a function (a builtin, perhaps, but it's not hard to write) that composes decorators: def compose(*decorators): def _(f): for d in decorators: f = d(f) return f our_attributes = compose(staticmethod, classmethod, otherattributes(debug=True)) def foo(bar, baz) [our_attributes]: pass -- Gareth McCaughan

On Mon, 2004-04-05 at 11:38, David Abrahams wrote:

Not bad. Also tolerable:

as [classmethod] def foo(bar, baz): pass

I thought we decided long ago that we can't use a keyword because no single keyword could sound right in the context of all possible use cases. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

On Mon, 2004-04-05 at 11:50, Shane Hathaway wrote:

Mark Russell wrote:

...

What about:

[as classmethod] def foo(bar, baz): pass

To me this is more obvious (and less like p*rl) that *[classmethod], and it is also currently a syntax error so won't break existing code.

I agree, it's nice. You could even use this syntax at the interactive prompt. The "is" keyword is another choice, too.

Since that is illegal syntax today, it would alleviate my primary concern with decorator-before-def syntax. And the 'as' keyword does help tie it to the following def. -Barry

What about:

[as classmethod] def foo(bar, baz): pass

To me this is more obvious (and less like p*rl) that *[classmethod], and it is also currently a syntax error so won't break existing code.

I appreciate the suggestion, but the current parser can't handle that. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

I appreciate the suggestion, but the current parser can't handle that.

Would it not be possible to cheat and make the lexer transform

"[" WHITESPACE "as" WHITESPACE IDENTIFIER

into an LBRACE-AS token (which I assume would make the parser's job simple).

I don't think without extreme hackery, but feel free to prove me wrong by producing a patch. (A problem is, there could be newlines and comments inside the WHITESPACE. Backtracking over that would require the lexer to have an arbitrary-length buffer.) --Guido van Rossum (home page: http://www.python.org/~guido/)

On Mon, 2004-04-05 at 19:59, Fred L. Drake, Jr. wrote:

Another possibility might be to require the construct start without the whitespace:

"[as" WHITESPACE ... "]"

That avoids the buffering issue and matches what most programmer are more likely to write anyway.

I think that's probably too arbitrary a restriction. Another thought: presumably the parser could handle this syntax if "as" were a keyword. Is that true, and if so, is making "as" a keyword out of the question? The change could presumably be enabled by a "from __future__" directive to avoid breaking existing code. Mark

In article <200404052209.i35M9m606023@guido.python.org>, Guido van Rossum wrote:

...

presumably the parser could handle this syntax if "as" were a keyword.

Not really. The parser is really dumb, it han only handle one alternative starting with a particular token at any point. Since '[' can already start an expression and an expression is a valid statement, anything else also starting with '[', even if it isn't a valid expression, cannot be accepted. You may be thinking of Yacc, which has much more liberal rules.

--Guido van Rossum (home page: http://www.python.org/~guido/)

Ok, then how about <decorator> def ... ? '<' can't start an expression or statement currently, can it? -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science

In article <3AA96ED4-876E-11D8-A42F-0003934AD54A@chello.se>, Simon Percivall wrote:

On 2004-04-06, at 01.24, David Eppstein wrote:

...

Ok, then how about <decorator> def ... ?

'<' can't start an expression or statement currently, can it?

Yeah. I think that would look better. On the other hand ...

On 2004-03-31, at 17.42, Guido van Rossum wrote:

...

Why does <...> look better than [...]? To me, <...> just reminds me of XML, which is totally the wrong association.

There are several parsing problems with <...>: the lexer doesn't see < and > as matched brackets, so you won't be able to break lines without using a backslash, and the closing > is ambiguous -- it might be a comparison operator.

Well, Mike Pall's long message "The Need for a Declarative Syntax" convinced me that some kind of bracketed prefix is the best location for these things, but I still don't like [...] because it already has a (useless) meaning, so declarators would pass silently in old Pythons. And the same objection applies to all other existing brackets. So, angle brackets seem like the cleanest remaining choice. Re the lexer, I don't see this as a big problem as long as multiple declarators can be handled by multiple <...> pairs. Re the ambiguity, I think comparisons shouldn't normally appear in declarators, so it's ok if they have to be parenthesized. -- David Eppstein http://www.ics.uci.edu/~eppstein/ Univ. of California, Irvine, School of Information & Computer Science

On Mon, 2004-04-05 at 19:03, Guido van Rossum wrote:

...

Would it not be possible to cheat and make the lexer transform

"[" WHITESPACE "as" WHITESPACE IDENTIFIER

into an LBRACE-AS token (which I assume would make the parser's job simple).

I don't think without extreme hackery, but feel free to prove me wrong by producing a patch. (A problem is, there could be newlines and comments inside the WHITESPACE. Backtracking over that would require the lexer to have an arbitrary-length buffer.)

Unless I'm missing something (very possible) there's no need to backtrack over the whitespace - all you need is a two-entry stack for the "[" and the token that follows. There's no question of INDENT or DEDENT because we're inside a [] pair. I've put a patch at python.org/sf/932100 which does this, plus changes to Grammar/Grammar, compile.c etc - it implements the syntax: [as classmethod] def foo(cls): pass The newline is optional: [as foo, bar, baz] def foo(cls): pass is also legal. The test suite passes as before (there are still two failures but they are unrelated to this patch). The patch also includes your test_decorators.py, modified for the new syntax. Mark

On Fri, 2004-04-09 at 01:36, Skip Montanaro wrote:

Does it treat '[' and 'as' as separate tokens so whitespace can occur between them?

Yes.

Note that the second alternative is likely to break all sorts of auxiliary tools which scan Python source. etags/ctags and python-mode come to mind. Clearly, python-mode is well within our domain, but other syntax coloring tools aren't.

It's a trivial change to disallow the second form - I'm pretty much 50/50 on whether it's a good idea to allow it or not. Probably "There's only one way to do it" should apply. (The change is trivial - in Grammar/Grammar, just replace [NEWLINE] with NEWLINE in the decorators entry). Mark

"Phillip J. Eby" :

There are different kinds of aesthetics. Guido's proposal has grown on me from a *visual* aesthetics point of view. After I worked with it a little bit, I realized it really is much prettier than decorators-before-colon.

Your tastes must be different from mine, then, because it doesn't strike me as any prettier visually, either. I don't think I can fully separate these different kinds of aesthetics in my mind, anyway. To me, a piece of syntax isn't just something to look at -- it has a grammar, and it has a meaning, and if the grammar and the meaning and the way it looks on the page don't all agree with each other, it strikes a discordant note. When I read the syntax def foo(args) [classmethod]: ... it says to me "Define a function foo, with these args, and which happens to be a classmethod. Here's the body..." On the other hand, when I see [classmethod] def foo(args): ... the little voice in my head doesn't really say anything coherent at all. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+

On Mon, Apr 05, 2004, Ka-Ping Yee wrote:

On Mon, 5 Apr 2004, Greg Ewing wrote:

...

the little voice in my head doesn't really say anything coherent at all.

Funny. I experience that most days.

"I do what the voices in my head tell me to." -- Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/ Why is this newsgroup different from all other newsgroups?

Greg Ewing wrote:

"Phillip J. Eby" :

...

There are different kinds of aesthetics. Guido's proposal has grown on me from a *visual* aesthetics point of view. After I worked with it a little bit, I realized it really is much prettier than decorators-before-colon.

Your tastes must be different from mine, then, because it doesn't strike me as any prettier visually, either.

What people find readable depends mostly on what they are used to. The reason Python is "so readable" on first read is because it rips off so much syntax directly from C, the language that is the ancestor for all of the other languages people use today. C doesn't have function decorators so people don't have expectations for them. But they will when they start coming over from C# and Java 1.5 in two or three years. One virtue of Guido's proposal is that it is basically what C# does. Java uses a pretty different syntax but it is also a prefix syntax. If Python uses a postfix syntax it will probably be alone in making that choice. I'm not saying that Python has to do what the other languages do because they do it, but all else equal, being familiar is better than being idiosyncratic (i.e. different for no good reason). So I would rank "like C# and Java" higher than "fits my personal aesthetics in early 2004" because aesthetics are likely to drift towards C# and Java over time. Paul Prescod

>> One virtue of Guido's proposal is that it is basically what C# >> does. Java uses a pretty different syntax but it is also a prefix >> syntax. If Python uses a postfix syntax it will probably be alone in >> making that choice. Guido> That's exactly Jim Hugunin's argument for this syntax. Since both C# and Java differ significantly in their typing from Python I suspect what works well for those languages (they already have a lot of declarative "baggage" because of their compile-time type checks, so what's a few more declarations?) may not work as well for Python. Second, Python has a strong tradition of borrowing what"works well" from other languages. I'm skeptical that C# has been around long enough to suggest that its syntax "works well". It's pretty clear that Microsoft is going to ram that down most programmers' throats, so the C# user base is no doubt going to be very large in a year or two. If what you're looking for is to provide a familiar syntactic base for C# refugees, then I suppose that's fine, but from the examples I've seen, C# decorations (annotations? attributes?) can be sprinkled quite liberally through the code (and serve as much to obscure as to highlight what's going on). A C# refugee might be disappointed to see that Python's decorators are limited to class, function and method declarations. With that in mind, it doesn't seem to me that partially mimicing C#'s decorator system is necessarily a good thing. Skip

Guido van Rossum wrote:

Anyway, personal aesthetics are learned behavior, like it or not.

Maybe yours. Mine are god-given. So there. --david

Paul Prescod :

I'm not saying that Python has to do what the other languages do because they do it, but all else equal,

But all else isn't equal, at least not for me, because I like one better than the other. If I didn't care one way or the other, I might look to another language for a tiebreaker. But I don't need to, because I already know which one I prefer. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+