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/pyt...st/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]

Paul McGuire wrote:

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]

Paul McGuire wrote:

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/pyt...st/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]

Jeff Shannon wrote:

My votes: J2 J2 E2

I second that. (J2 J2 E2)

-Peter

[Steven Bethard]

David Fraser <davidf <at> sjsoft.com> writes:

J2 L L

I second that.

Steve

[Andrew Durdin]

As for me?

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

[Robin Becker]

Paul McGuire wrote:

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?
--
Robin Becker

[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

--
Ayose Cazorla León
Debian GNU/Linux - setepo

[Arien Malec]

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in
news:t0****************@fe2.texas.rr.com:

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

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Anthony Baxter]

On Fri, 20 Aug 2004 01:37:07 +0100, Robin Becker
<ro***@spamremovejessikat.fsnet.co.uk> wrote:

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]

On Thu, 19 Aug 2004 19:16:41 GMT, Paul McGuire
<pt***@austin.rr._bogus_.com> wrote:

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]

"Arien Malec" <ar*********@yahoo.com.REMOVE> wrote in message
news:Xn********************************@64.164.98. 7...

"Paul McGuire" <pt***@austin.rr._bogus_.com> wrote in
news:t0****************@fe2.texas.rr.com:

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

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

[Egbert Bouwman]

My vote: C1 D1 K
egbert
--
Egbert Bouwman - Keizersgracht 197 II - 1016 DS Amsterdam - 020 6257991
================================================== ======================

[Paul Rubin]

"Paul McGuire" <pt***@austin.rr._bogus_.com> writes:

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

[Bruno Desthuilliers]

Paul McGuire wrote:

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

[Nicolas Fleury]

Paul Rubin wrote:

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

[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

--
Ciao,
Matteo

[Peter Otten]

Paul Rubin wrote:

"Paul McGuire" <pt***@austin.rr._bogus_.com> writes:

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.

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

[Anthony Baxter]

On 20 Aug 2004 00:31:35 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:

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.

[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

--
Gaudi systems architecting:
<http://www.extra.research.philips.com/natlab/sysarch/>

[Gerrit Muller]

Paul Rubin wrote:

"Paul McGuire" <pt***@austin.rr._bogus_.com> writes:

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.

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

regards Gerrit

--
Gaudi systems architecting:
<http://www.extra.research.philips.com/natlab/sysarch/>

[Anthony Baxter]

On Fri, 20 Aug 2004 10:51:00 +0200, Gerrit Muller
<ge***********@embeddedsystems.nl> wrote:

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.
--
Mi************@rd.bbc.co.uk
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.

[Roman Suzi]

My vote:

C4 A1 J2

(Though, J2 with different keyword, not "decorate")
Sincerely yours, Roman A.Suzi
--
- Petrozavodsk - Karelia - Russia - mailto:rn*@onego.ru -

[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/communi...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...arpspec_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...sreference.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...attributes.asp

Neil

[Ville Vainio]

>>>>> "Paul" == Paul McGuire <pt***@austin.rr._bogus_.com> writes:

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).

--
Ville Vainio http://tinyurl.com/2prnb

[Peter Hansen]

Peter Hansen wrote:

Jeff Shannon wrote:

My votes: J2 J2 E2

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

[Sion Arrowsmith]

Paul McGuire <pt***@austin.rr._bogus_.com> wrote:

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.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[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 8-)

--
Richie Hindle
ri****@entrian.com

[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)

[David Fraser]

Peter Hansen wrote:

Peter Hansen wrote:

Jeff Shannon wrote:

My votes: J2 J2 E2

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.

Exactly. From this standpoint, the list on the wiki should be filtered
to something that
1) doesn't have the declaration in the body of the function
2) doesn't have the declaration following the parameters

1) rules out D1 D2 E1 E2
2) rules out C1 C2 C3 C4 E3

This leaves (with A left out as we're looking at alternatives)
B F G H I J1 J2 J3 J4 K L M

With the voting going the way it currently is J2 is winning anyway, the
only current close competitor would be C1 or a variant, but I think it
looks like J2 is going to be the one to form a concensus around.
(Current ranking is J2=38, C1=18, C1+C2+C3+C4=25, next highest is F=6,
out of 34 voters giving 102 votes).

The other one I supported was L but that's more on the basis of
if-we-have-to-have-it-this-way-at-least-make-it-a-keyword-not-a-punctuation-character
which I guess could always be argued for if J2 doesn't get it.

David

[Darren Dale]

J2,J2,J2

[Paolino]

d2 d2 j2

Thanks for the piece of democracy

[Paolino]

d2 d2 j2

Thanks for the piece of democracy

[Istvan Albert]

Paul McGuire wrote:

The significant alternatives have been listed on the Python wiki at
http://www.python.org/moin/PythonDecorators .
This page lists all the choices and not just the alternatives.
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 have noticed that many people thought (or implied) that they
should be voting only for alternatives. Others voted for the
the existing implementation. This makes this poll even more
unreliable than usually.

I don't think one should ever devise a poll to test for
*second* options only. The second option only makes sense
in proper context when compared to the first option.

As more an more syntaxes came up and faced with increasingly
hairy syntaxes and heated arguments I start to believe
that Guido's choice is actually the best.

A1 E1

Istvan.

[David Fraser]

Istvan Albert wrote:

Paul McGuire wrote:

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

This page lists all the choices and not just the alternatives.

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 have noticed that many people thought (or implied) that they
should be voting only for alternatives. Others voted for the
the existing implementation. This makes this poll even more
unreliable than usually.

I don't think one should ever devise a poll to test for
*second* options only. The second option only makes sense
in proper context when compared to the first option.

Thats because the point of this vote is to try and gather a consensus
about what the best alternative is, not to try and out-vote the original
contender. The final decision will rest with Guido anyway, so we just
want to get together the best possible alternative proposal

David

[Dan Pierson]

J2 J2 J2

[John Crichton]

Hi,

My vote: J2 J2 J2.

Surely any English language keyword that gives a meaningful hint as to
its purpose within a program has to be more readable than an arbitrary
'@' symbol?

Readability is one of Python's key strengths and I would be very sorry
to see this undermined.

Best wishes,

John

[Istvan Albert]

John Crichton wrote:

Surely any English language keyword that gives a meaningful hint as to
its purpose within a program has to be more readable than an arbitrary
'@' symbol?

so what is more 'readable'

x[1:10]

or

x[from 1 to 10 ]

[Paul McGuire]

"Ville Vainio" <vi***@spammers.com> wrote in message
news:du*************@mozart.cc.tut.fi...

>> "Paul" == Paul McGuire <pt***@austin.rr._bogus_.com> writes:

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).

--
Ville Vainio http://tinyurl.com/2prnb

Ville -

I'm afraid I have to agree, the subject is a poor one. I noticed that
yesterday as the responses were slow to come in. Something more on the
order of "READ THIS - IT'S FREAKIN' IMPORTANT!" is surely warranted.

I am still relatively new to Usenet, and surely not aware of how to update
the subject of an existing post, otherwise I would have done so!

But please don't abstain in voting over my poor judgment in titling this
thread, the responses are starting to trickle in (there was already a
cross-mention on python-dev). And I would not at all be offended if you
posted an additional note with some more-appropriate subject, directing
people to this process.

Thanks,
-- Paul

[Reinhold Birkenfeld]

Paul McGuire wrote:

[Decorators]

J2 J2 J2

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc