Poll - Vote here for "list-after-def" (was Decorator syntax)

[Istvan Albert]

Paul McGuire wrote:

Please reconsider the "def f() [classmethod]:" construct. Instead of
invoking a special punctuation character, it uses context and placement,
with familiar old []'s, to infuse the declaration of a function with special
characteristics. If this causes def lines to run longer than one line,
perhaps the same rule that allows an unmatched "(" to carry over multiple
lines without requiring "\" continuation markers could be used for unmatched
"["s, as in:

def f() [ staticmethod,
synchronized,
alphabetized,
supersized,
returns('d') ]:

Well said!

Reading the posts here and in the python-dev I've counted
the following votes for it (I'm sure that there were a lot
more but it is awfully hard to keep up with the posts
on the topic).

Voting for the "list-after-def" syntax as shown above:

Peter Hansen <pe***@engcorp.com>
AdSR <ar**********@yahoo.com>
Paul McGuire <pt***@austin.rr._bogus_.com>m
Phillip J. Eby pje at telecommunity.com
C. Barnes <co************@yahoo.com>
Aahz aahz at pythoncraft.com
Skip Montanaro skip at pobox.com
Bill Janssen janssen at parc.com
Istvan Albert ia*****@mailblocks.com

I have the feeling that this always was and still is
the favorite.

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

Istvan.

[Greg Krohn]

Istvan Albert wrote:

Paul McGuire wrote:

Please reconsider the "def f() [classmethod]:" construct.

I concur.

The @ construct is atrocious and *very* unpythonic. I would choose no
changes at all over implementing the @ construct. list-after-def is
much, much, *much* better.
Greg Krohn
(I feel more strongly about this than I did (do) about PEP 308.)

[Anthony Baxter]

The solution, if you don't like the syntax, is not voting. It's to propose an
argument that Guido will accept, in favour of your preferred option.

[Andrew Durdin]

On Thu, 05 Aug 2004 22:39:19 -0400, Istvan Albert
<ia*****@mailblocks.com> wrote:

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

+1

I greatly prefer it over the @ syntax.

[Jean Brouwers]

The "list-after-def" is my preference as well, more than +1. It
matches existing Python syntax by using a list (or tuple?) notation,
the list of keywords can span one or multiple lines and it can easily
be extended with additional keywords as the need arises in the future.

Apart from being non-Pythonic, my objection against the @ proposal is
that it can easily be confused with comments like the (Java) doc-like
notations.

I am not qualfied to judge backward possible compatibility issues.

/Jean Brouwers

In article <6L********************@giganews.com>, Istvan Albert
<ia*****@mailblocks.com> wrote:

Paul McGuire wrote:

> Please reconsider the "def f() [classmethod]:" construct. Instead of
> invoking a special punctuation character, it uses context and placement,
> with familiar old []'s, to infuse the declaration of a function with
> special
> characteristics. If this causes def lines to run longer than one line,
> perhaps the same rule that allows an unmatched "(" to carry over multiple
> lines without requiring "\" continuation markers could be used for
> unmatched
> "["s, as in:
>
> def f() [ staticmethod,
> synchronized,
> alphabetized,
> supersized,
> returns('d') ]:

Well said!

Reading the posts here and in the python-dev I've counted
the following votes for it (I'm sure that there were a lot
more but it is awfully hard to keep up with the posts
on the topic).

Voting for the "list-after-def" syntax as shown above:

Peter Hansen <pe***@engcorp.com>
AdSR <ar**********@yahoo.com>
Paul McGuire <pt***@austin.rr._bogus_.com>m
Phillip J. Eby pje at telecommunity.com
C. Barnes <co************@yahoo.com>
Aahz aahz at pythoncraft.com
Skip Montanaro skip at pobox.com
Bill Janssen janssen at parc.com
Istvan Albert ia*****@mailblocks.com

I have the feeling that this always was and still is
the favorite.

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

Istvan.

[AdSR]

Istvan Albert <ia*****@mailblocks.com> wrote in message news:<6L********************@giganews.com>...

Paul McGuire wrote:

> Please reconsider the "def f() [classmethod]:" construct. Instead of
> invoking a special punctuation character, it uses context and placement,
> with familiar old []'s, to infuse the declaration of a function with special
> characteristics. If this causes def lines to run longer than one line,
> perhaps the same rule that allows an unmatched "(" to carry over multiple
> lines without requiring "\" continuation markers could be used for unmatched
> "["s, as in:
>
> def f() [ staticmethod,
> synchronized,
> alphabetized,
> supersized,
> returns('d') ]:

Well said!
<snip>
I have the feeling that this always was and still is
the favorite.

By the way, does anybody remember the first proposed syntax?

def f() as staticmethod, synchronized, alphabetized, \
supersized, returns('d'):
pass

Nowadays I'm more in favor of the list syntax, since in the future it
could be dynamized by allowing list comprehension. Not that you can't
achieve the same goal with static decorator list, using a decorator
that iterates over that dynamic list of decorators that you want.

Waking-up-the-dead-ly yours,

AdSR

[Michel Claveau - abstraction méta-galactique non t]

Vote...

And what is the position from Kerry and/or Bush ?

[Peter Hansen]

Istvan Albert wrote:

Paul McGuire wrote:

> Please reconsider the "def f() [classmethod]:" construct.
>
> def f() [ staticmethod,
> synchronized,
> alphabetized,
> supersized,
> returns('d') ]:

Nobody has bothered to post an example with a long argument list,
thus ignoring the possibly valid claim in the PEP that this would
make the decorator list hard to see. Here goes:

def someMethod(self, posArgOne, anotherArg,
fieldX=56,
x=5, y=7, z=9,
**kwargs)
[
staticmethod,
synchronized,
alphabetized,
supersized,
returns('d')
]:

Okay, pretty much an abomination, but I'm not sure it's any worse than
the alternative with @:

@staticmethod
@synchronized
@alphabetized
@supersized
@returns('d')
def someMethod(self, posArgOne, anotherArg,
fieldX=56,
x=5, y=7, z=9,
**kwargs):

It *is*, however, fairly clear that the list of decorators becomes
harder to see. Without checking, it's definitely possible that the
decorator list in the first case is actually part of the argument list.

I don't care. I still prefer it to @, if nothing else because
it's much more intuitive to a Python programmer what order they
will be applied in.
Voting for the "list-after-def" syntax as shown above:

Apparently the term "voting" is deprecated when related to PEPs
and language design. ;-) Instead, we should now be using the term
"expressing their opinion in favour of"...

At least, I hope we are still allowed to express opinions in favour
of things...

-Peter

[Christopher T King]

On Thu, 5 Aug 2004, Istvan Albert wrote:

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

My vote goes to this. If we have to have decorators, this is how they
should look.

[Christian Tismer]

Istvan Albert wrote:

....

Ladies and Gents, start your engines and rally around
this syntax (if you prefer it of course) so that there
is evidence that it should be taken as a serious candidate.

You have my full support.
Although I'm not sure if we still have an option
to choose at all.

+1

--
Christian Tismer :^) <mailto:ti****@stackless.com>
Mission Impossible 5oftware : Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/
14109 Berlin : PGP key -> http://wwwkeys.pgp.net/
work [phone] home [phone] mobile [phone]
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

The solution, if you don't like the syntax, is not voting. It's to
propose an argument that Guido will accept, in favour of your preferred
option.

We can't propose a dozen different syntaxes. We're voting for our
benefit, not his. The argument presented will be built around the syntax
voted for here.

[Christopher T King]

On Fri, 6 Aug 2004, Michel Claveau - abstraction méta-galactique non triviale en fuite perpétuelle. wrote:

And what is the position from Kerry
"Decorators should come in a list after the function definition. Having
decorarotrs in a list before the function definition is surely the best
way to go. When you have @decorators, everything works out well. Adding
keywords is what this country is all about!"
and/or Bush ?

"Is our decorators working?"

[Anthony Baxter]

On Fri, 06 Aug 2004 08:24:47 -0400, Peter Hansen <pe***@engcorp.com> wrote:

It *is*, however, fairly clear that the list of decorators becomes
harder to see. Without checking, it's definitely possible that the
decorator list in the first case is actually part of the argument list.
This is one of the reasons Guido rejected it, see
http://mail.python.org/pipermail/pyt...st/047112.html
Apparently the term "voting" is deprecated when related to PEPs
and language design. ;-) Instead, we should now be using the term
"expressing their opinion in favour of"...
Well, it's not so much deprecated as pointless <wink>
At least, I hope we are still allowed to express opinions in favour
of things...

In case it wasn't clear from my earlier posts - my comments about "voting"
being a waste of time were meant in the sense of "collecting a bunch of
votes won't achieve anything". Collecting a rationale that is sufficient to
change Guido's mind, however, is encouraged! But simply saying "here's
a list of people who prefer this syntax" won't achieve much at all. Far
better use of time is to work out a way to convince Guido to change his
mind (which, it should be clear from the post above, will require a strong
argument, with good reasons for it).

[Edward K. Ream]

> Please reconsider the "def f() [classmethod]:" construct.

+1 from me.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Greg Krohn]

Anthony Baxter wrote:

The solution, if you don't like the syntax, is not voting. It's to propose an
argument that Guido will accept, in favour of your preferred option.

Yes, I suppose so. +1 in favor of Anthony's proposal to come up with a
persuasive argument instead of 'voting'. ;)

The reason I don't like the proposed @ construct is that the decorators
don't seem to be actually part of the function def. They seem to be
separate statements before the def. With the list-after-def construct
the decorators appear after 'def' and before ':'; clearly part of the
function def.

I will concede that the @ example someone posted with a long argument
list is slightly more readable than the corresponding list-after-def.
BUT, I think with a shorter arg list list-after-def is more
readable/intuitive. I believe that shorter args lists are more common
than long ones. I think the decorator syntax should favor the more
common usage.
Greg Krohn

[Michel Claveau - abstraction méta-galactique non t]

;o)

[Bengt Richter]

On Fri, 06 Aug 2004 08:24:47 -0400, Peter Hansen <pe***@engcorp.com> wrote:

Istvan Albert wrote:

Paul McGuire wrote:

> Please reconsider the "def f() [classmethod]:" construct.
>
> def f() [ staticmethod,
> synchronized,
> alphabetized,
> supersized,
> returns('d') ]:

Nobody has bothered to post an example with a long argument list,
thus ignoring the possibly valid claim in the PEP that this would
make the decorator list hard to see. Here goes:

def someMethod(self, posArgOne, anotherArg,
fieldX=56,
x=5, y=7, z=9,
**kwargs)
[
staticmethod,
synchronized,
alphabetized,
supersized,
returns('d')
]:

Okay, pretty much an abomination, but I'm not sure it's any worse than
the alternative with @:

@staticmethod
@synchronized
@alphabetized
@supersized
@returns('d')
def someMethod(self, posArgOne, anotherArg,
fieldX=56,
x=5, y=7, z=9,
**kwargs):

It *is*, however, fairly clear that the list of decorators becomes
harder to see. Without checking, it's definitely possible that the
decorator list in the first case is actually part of the argument list.

It seems to me that all the proposed syntaxes have in common the purpose
of creating an ordered set of functions to be applied in order to the
result of a def. Why not accept this and use a builtin object to hold
the temporary function sequence? Thus you could have a method (or __call__)
add one or more functions to the temporary set contained in the builtin object.

Then the list of functions can be the argument list to a method of the builtin
object instead of list syntax magically interpreted in list-after-def context,
magically saving the sequence in a magic internal place (as opposed to programmer-known
and overrideable). If you had a builtin object and a builtin userfriendly
alias for a method that adds one or more decorators to its list (that gets used
up at the end of the next def), then you could write (picking decorate as user-friendly ;-)

decorate(staticmethod, synchronized, alphabetized, supersized)
decorate(returns('d'))
def someMethod(self, posArgOne, anotherArg,
fieldX=56,
x=5, y=7, z=9,
**kwargs
): #I like it better here for multiline arg lists ;-)
# ...

def implementation would have to be modified to look for the builtin object
and get the decorator functions from there. You could choose to look for
a shadowing name binding starting with locals(), or you could only allow
a shadowing starting at globals() I suppose, for speed.

BTW, is @decorator thread-safe? I guess it would be something to be careful
about in a really dynamic object-oriented implementation.
I don't care. I still prefer it to @, if nothing else because
it's much more intuitive to a Python programmer what order they
will be applied in.

'@x' as a spelling of
__programmer_inaccessible_hidden_system_temp_list. append(x) # or is it 'x' ?
seems not the best use of '@' to me.

Regards,
Bengt Richter

[Reinhold Birkenfeld]

Istvan Albert wrote:

Voting for the "list-after-def" syntax as shown above:

Peter Hansen <pe***@engcorp.com>
AdSR <ar**********@yahoo.com>
Paul McGuire <pt***@austin.rr._bogus_.com>m
Phillip J. Eby pje at telecommunity.com
C. Barnes <co************@yahoo.com>
Aahz aahz at pythoncraft.com
Skip Montanaro skip at pobox.com
Bill Janssen janssen at parc.com
Istvan Albert ia*****@mailblocks.com

+1

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