Alternative decorator syntax decision

[Paul McGuire]

There are a number of messages on the python-dev mail list that indicate
that Guido is looking for some concensus to come from this list as to what
*one* alternative syntax for decorators we would like him to consider in
place of the @ syntax that is currently in 2.4a2.

I think special thanks are due to:
- Anthony Baxter for his continuing efforts in this regard
- Steven Bethard for some of the clearest thinking and writing on this topic
- Michael Sparks for actually implementing one of the options

We've all done our share of pitching and whining, but we need to settle on
*one* option for Guido to consider.

(And let's not get wrapped up complaining about the "process" being followed
in this whole thing, personally I think it is quite poor. But let's play
with the cards we've been dealt, and at least make a collective proposal.)

The significant alternatives have been listed on the Python wiki at
http://www.python.org/moin/PythonDecorators .

Interested parties should also look at the comments in the python-dev
archive for the past month, at
http://mail.python.org/pipermail/python-dev/2004-August/thread.html .

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.

I am not going to argue that this is scientific in any respect, but it
*should* allow the major 1 or 2 choices to bubble to the top. I have used
this process at work many times in the past when it was necessary for a
large group to set priorities among a large list of choices.

My vote is: J2 J2 C1

By the way, once an option has been chosen, it *still* needs an
implementation for Guido to accept it. This puts some of the options way
ahead of the others, in my mind.

(And let's hope we get at least as good a response as the "average age"
thread!)

-- Paul

 

[Jeff Shannon]

I think special thanks are due to:
- Anthony Baxter for his continuing efforts in this regard
- Steven Bethard for some of the clearest thinking and writing on this topic
- Michael Sparks for actually implementing one of the options

I'd definitely second these special thanks.

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.

This seems like a fairly reasonable way of at least getting an
estimation of concensus. I'd also suggest that, if there's a large
number of votes distributed between minor variations on a theme (i.e.
they differ as to what character/keyword to use), that might be
considered as a sum. If, for example, E1 and E2 are the second and
third most popular choices, with a total that's higher than that of the
most popular choice, it seems reasonable to me to consider them to be
the "winner" and to then discuss which character is preferred. This is
hard to codify, however, as some of the numbered variants are
significantly different while others are only slightly different...

My votes: J2 J2 E2

Jeff Shannon
Technician/Programmer
Credit International

 

[David Fraser]

There are a number of messages on the python-dev mail list that indicate
that Guido is looking for some concensus to come from this list as to what
*one* alternative syntax for decorators we would like him to consider in
place of the @ syntax that is currently in 2.4a2.

I think special thanks are due to:
- Anthony Baxter for his continuing efforts in this regard
- Steven Bethard for some of the clearest thinking and writing on this topic
- Michael Sparks for actually implementing one of the options

We've all done our share of pitching and whining, but we need to settle on
*one* option for Guido to consider.

(And let's not get wrapped up complaining about the "process" being followed
in this whole thing, personally I think it is quite poor. But let's play
with the cards we've been dealt, and at least make a collective proposal.)

The significant alternatives have been listed on the Python wiki at
http://www.python.org/moin/PythonDecorators .

Interested parties should also look at the comments in the python-dev
archive for the past month, at
http://mail.python.org/pipermail/python-dev/2004-August/thread.html .

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.

I am not going to argue that this is scientific in any respect, but it
*should* allow the major 1 or 2 choices to bubble to the top. I have used
this process at work many times in the past when it was necessary for a
large group to set priorities among a large list of choices.

My vote is: J2 J2 C1

By the way, once an option has been chosen, it *still* needs an
implementation for Guido to accept it. This puts some of the options way
ahead of the others, in my mind.

J2 L L

I hope once the major 2 choices or so are clear that there is another
discussion about how to select one

David

 

[Peter Hansen]

My votes: J2 J2 E2

I second that. (J2 J2 E2)

-Peter

 

[Egbert Bouwman]

My vote: C1 D1 K
egbert

 

[Steven Bethard]

J2 L L

I second that.

Steve

 

[Andrew Durdin]

As for me?

J2, C1, um.... er... J2.

 

[Robin Becker]

There are a number of messages on the python-dev mail list that indicate
that Guido is looking for some concensus to come from this list as to what
*one* alternative syntax for decorators we would like him to consider in
place of the @ syntax that is currently in 2.4a2.

.....

Is there any discussion about which versions are currently legal python
in Python-2.x x<4? I deal with lot's of cross version maintainance
issues and the very worst are where the syntax makes it illegal even to
compile the files. I believe that B is legal and has implementations for
earlier pythons available, but are others?

 

[Ayose]

[Paul McGuire]

[...]
The significant alternatives have been listed on the Python wiki at
http://www.python.org/moin/PythonDecorators .

My vote is: C2 C2 C1

 

[Arien Malec]

There are a number of messages on the python-dev mail list that
indicate that Guido is looking for some concensus to come from this
list as to what *one* alternative syntax for decorators

M, any keyword option using "transform"

(I care more about semantics than syntax)

Arien

 

[Greg Ewing]

My vote: C1 D1 E1

 

[Anthony Baxter]

Is there any discussion about which versions are currently legal python
in Python-2.x x<4? I deal with lot's of cross version maintainance
issues and the very worst are where the syntax makes it illegal even to
compile the files. I believe that B is legal and has implementations for
earlier pythons available, but are others?

Backwards compatibility is not considered a desirable goal.

Don't forget that any code that uses generator expressions is _also_
invalid in Python 2.3 and earlier - and they'll be used a hell of a lot
more than decorators.

 

[Anthony Baxter]

We've all done our share of pitching and whining, but we need to settle on
*one* option for Guido to consider.

Also note that Python 2.4a3 is currently targetted at September 2. So there
_is_ a time constraint.

This is 4 weeks after a2. I considered the impact that this would have on the
alternate decorators proposals, and decided that it didn't matter - the threads
here and on python-dev have more or less hit a steady-state.

 

[Skip Montanaro]

Paul> I would propose a multivote survey: each poster gets 3 votes among
Paul> the lettered choices on the Wiki page above. You can use all 3
Paul> for a single option, or split them across 2 or 3 options if you
Paul> are open to more than one.

C1 C1 J2

Skip

 

[Paul McGuire]

M, any keyword option using "transform"

(I care more about semantics than syntax)

Arien

I can interpret "any keyword option using "transform"" to match J1, J2, or
L.

Please narrow "any keyword option using "transform"" down to 2 specific
choices, otherwise I can only tally your vote for "M".

-- Paul

 

[Peter Otten]

My vote:

J2 J2 K

Preferred keyword: transform

I could live with the pie, though.

Peter

 

[Paul Rubin]

I would propose a multivote survey: each poster gets 3 votes among the
lettered choices on the Wiki page above. You can use all 3 for a single
option, or split them across 2 or 3 options if you are open to more than
one.

1. My favorite variant was not in the list.

2. Any of the choices will have far reaching consequences that aren't
yet thought out very well. There is not yet enough experience
programming with the existing mechanisms (classmethods etc.) to
be sure what's really worthwhile.

3. There's not all that much discussion on the wiki of how other
languages do this stuff.

4. There's nowhere near consensus that any of the choices presented so
far are not plain horrible.

My conclusion: Python 2.4 should not have new decorator syntax. Stay
with the existing stuff, for now.

Discussion and exploration should continue and the question should be
revisited for 2.5. For 2.4, extend the current kludgy (decorators
separated from the function) mechanism if needed to provide necessary
functionality, but deprecate any new such feature as soon as it's
introduced, with the explanation that it's exploratory.

 

[Nicolas Fleury]

You've been quicker than me to post "Alternative decorator syntax
decision". My post doesn't appear in the newsgroup on my side, so I
post it in this thread.

Hi all,

The part of the Python community that doesn't like @decorators needs to
unite behind an alternative syntax to propose to Guido. I suggest we
use this thread to try to do it. If you agree with @decorators, then I
suggest you stop reading this message

Many syntaxes have been put on http://www.python.org/moin/PythonDecorators.

I suggest to fight the current @descriptors on these two points:
- Less Readable. The @ character adds a new character with a magical
sense. It doesn't read in english as the rest of Python.
- Not Pythonic. It's a line without a block (like try/finally) that
affects a following line of code. It breaks interactive shells.

I suggest that the alternative syntax to be both more readable and more
pythonic. Many syntaxes have been ruled out by Guido, but he seems to
be open to a new keyword accessible with a "from __future__ import".
Since a new keyword would make the syntax more readable (and easier to
find doc about), I suggest to discuss these two alternatives, not
necessarily with these keywords:

Proposal 1:

decorate: staticmethod
def foo(a, b):
...

decorate:
accepts(int,int)
returns(float)
def bar(low, high):
...

other possible keywords: predef, from, as, with

This proposal has basically the advantages of @decorators with a more
Pythonic approach. The main drawback is that the decorate block doesn't
contain anything like normal statements, as with @decorators.
Implementation already exists.


Proposal 2:

def foo(a,b):
using staticmethod
...

def bar(low, high):
using accepts(int, int)
using returns(float)

other possible keywords: decorate, transform, with, postdef, as

The pool on Wiki suggest that most people would prefer an inside def
syntax. It would place decorators at the same place as docstrings,
which is very Pythonic, since it's consistent with the rest of the
language. The main concern is that it places information that can be
important to callers far from the def. I guess the answer would be that
it's not that far from the def and that sometimes the parameters names
would give strong hints about the decorators. For example, even if it's
not forced by the language, a method with a first parameter not named
self would be strong hint to check the first line of the body to see if
it's a static method, etc. I suggest to force descriptors to be before
the docstring to make them as closer as possible to the def and ease
finding them. (Another answer could be that scanning down from the def
is not that more bad than scanning up from the def).
Is there any implementation existing?

My questions would be: which of these proposals do you prefer to current
@decorators. Both? None?

What keywords would you prefer? Do you see any that I have not listed?

Do you think there's an alternative that I should have listed, even
considering what have been ruled out by Guido?

Regards,

Nicolas

 

[Nicolas Fleury]

My vote: E4, J2, K

 

[Nicolas Fleury]

1. My favorite variant was not in the list.

What is it? I added E4 before voting because it was not on the list

Regards,
Nicolas