Alternative decorator syntax decision

[Ben]

My vote:

C1 C1 E1

Note it would have been C1 C1 A but I am voting on _alternatives_ to A.
I think this is what you want?

Ben

 

[Greg Krohn]

My vote: C1 D2 J2

Greg Krohn

 

[Matteo Dell'Amico]

I, J2 (I find "transform" a good choice for a keyword), H

 

[Peter Otten]

1. My favorite variant was not in the list.

I suggest that you add it.

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.

The PyObjC and (some?) Zope people say they need "fancy" decorators badly.
Classmethods are comparatively straight-forward.

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

I think Java and C# have been discussed on python-dev. Again you could share
your experience.

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.

D'accord. The most promising way to achieve that is to collect arguments
against the pie that can convince Guido and find a contender that has at
least the same level of support in the community.
On a side note, I think it strange that aesthetics are ruled out. Certainly
neither the decorator suite nore the pies can be advertised as "executable
pseudocode".

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.

Those who need decorators will adopt the included syntax even if it is not
their favourite. I guess that unless technical problems appear yours will
be an effective vote for the @decorator.

Peter

 

[Roman Suzi]

My vote:

C4 A1 J2

(Though, J2 with different keyword, not "decorate")


Sincerely yours, Roman A.Suzi

 

[Anthony Baxter]

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

This is not an option that is going to happen. The decorators thread
has been discussed on python-dev for 2 1/2 years. The case for including
them has been decided. The original decorators (classmethod, staticmethod)
were introduced in Python 2.2, released late 2001. How long do you think
we should wait?

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.

This is not the way Python works. "experimental" stuff doesn't stay experimental
once the first beta release is out. I see no reason to change this -
it increases
the costs dramatically for companies who are using Python if they have to
rewrite their code every second release.

 

[Bruno Desthuilliers]

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.

My vote is F, F and F.
Bruno

 

[Gerrit Muller]

I miss the option to _not_introduce decorators at all, at least at this
moment. Reading the discussion and all different proposals, it is
entirely clear for me that we don't know at the moment what the exact
goal is that we desire. Despite the lack of goal we shoot all kinds of
complicating and poorly readable options into the air. Be aware: once
something is introduceed you will not be able to remove it again.
Introduction is relatively easy, removal is nearly impossible.

In absence of my real vote (delay, delay, do nothing), I vote:
F F A1

regards, Gerrit

 

[Gerrit Muller]

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.

Hear, Hear! I just replied in a similar way, before reading your response.

regards Gerrit

 

[Anthony Baxter]

I miss the option to _not_introduce decorators at all, at least at this
moment.

That's because that's not an option that's on the table. Stating you don't
want them won't achieve anything at all.

 

[Scott Gilbert]

C1 C1 C1

 

[Michael Sparks]

Paul McGuire wrote:
....

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.

My vote is: J2 J2 C1


Michael.
--
(e-mail address removed)
British Broadcasting Corporation, Research and Development
Kingswood Warren, Surrey KT20 6NP

This message (and any attachments) may contain personal views
which are not the views of the BBC unless specifically stated.

 

[Neil Hodgson]

Peter Otten:

I think Java and C# have been discussed on python-dev. Again you could share
your experience.

@java
http://www.jcp.org/aboutJava/communityprocess/review/jsr175/

///@XDoclet was a forerunner that hid the @s inside doc comments
http://xdoclet.sourceforge.net/xdoclet/index.html

[C# attributes] can be user defined but are static pieces of metadata.
http://msdn.microsoft.com/library/en-us/csspec/html/vclrfcsharpspec_17.asp
The "eXtensible C#" language extends this to allow compile time actions.
http://www.resolvecorp.com/products.aspx

Visual C++ attributes are not currently user definable but can inject
code into the output object files. Attributes can only be defined by
Microsoft who have not documented the interface between the compiler and the
attribute provider DLLs. Microsoft have been promising user defined
attributes for a few years now. "Ronald Laeremans attributes" is a good
google key.
http://msdn.microsoft.com/library/en-us/vcattrib/html/vcrefattributesreference.asp

Microsoft IDL has had a hard coded set of attributes using the [] before
definition syntax for about 15 years
http://msdn.microsoft.com/library/en-us/midl/midl/idl_attributes.asp

Neil

 

[Ville Vainio]

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

Not going to happen, with the words "alternative decorator syntax" in
the subject. No sensible person wants to see yet another wacky
alternative, and the subject promises as much.

Hence, I won't vote yet because, at minimum, you need a better subject
line.

Something like this needs to be announced somewhere (e.g. daily
python-url).

 

[Peter Hansen]

I second that. (J2 J2 E2)

I believe that the result the direction this is taking is
inevitable: a widely split vote with no consensus. I did
think there was much more agreement about which one was the
best alternative, warts and all, to @pie and which one was
therefore the most likely to get any attention at all from
Guido. I also thought people had a better grasp of which
ones had already been *rejected* fairly conclusively.

Don't people who are voting for the obscure ones understand
that this is likely to result in a no-decision, and therefore
a decision for @pie by default?

I'd like to change my vote to J2 J2 J2.

-Peter

 

[Dennis Benzinger]

My favorites are: J2 J2 K

 

[djo]

J2 J2 L



I like keywords instead of symbols. Although I've started
thinking of the @ as "a" for "apply decorating function". I
don't read python-dev, what that intentional?



djo (lurker, using Python for image analysis software for
electron microscopy)

 

[Sion Arrowsmith]

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

C2 C2 J2

I'm really not sure what I don't like about the @ syntax. Most of
the time it's the idea that a statement at a given indentation level
affects *just* the next suite, not the rest of the file. Then I look
at the J options (other than J1) which are doing much the same thing
and seem reasonable (if not my first choice), and think maybe it's
the line-noise effect of the "@". But decorators aren't something I
can see myself making much (if any) use of, so I'll live with
whatever they turn out as.

 

[Paolino]

d2 d2 j2

Thanks for the piece of democracy

 

[Richie Hindle]

each poster gets 3 votes among the lettered choices on the Wiki page above.

H I J2

Kudos to Paul for arranging this. I hope it works (for some value of
'works' that we can vote on later