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

Discussion in 'Python' started by Istvan Albert, Aug 6, 2004.

  1. 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 <>
    AdSR <>
    Paul McGuire <._bogus_.com>m
    Phillip J. Eby pje at telecommunity.com
    C. Barnes <>
    Aahz aahz at pythoncraft.com
    Skip Montanaro skip at pobox.com
    Bill Janssen janssen at parc.com
    Istvan Albert

    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.
     
    Istvan Albert, Aug 6, 2004
    #1
    1. Advertising

  2. Istvan Albert

    Greg Krohn Guest

    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.)
     
    Greg Krohn, Aug 6, 2004
    #2
    1. Advertising

  3. 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.
     
    Anthony Baxter, Aug 6, 2004
    #3
  4. On Thu, 05 Aug 2004 22:39:19 -0400, 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.


    +1

    I greatly prefer it over the @ syntax.
     
    Andrew Durdin, Aug 6, 2004
    #4
  5. 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 <>, Istvan Albert
    <> 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 <>
    > AdSR <>
    > Paul McGuire <._bogus_.com>m
    > Phillip J. Eby pje at telecommunity.com
    > C. Barnes <>
    > Aahz aahz at pythoncraft.com
    > Skip Montanaro skip at pobox.com
    > Bill Janssen janssen at parc.com
    > Istvan Albert
    >
    > 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.
    >
     
    Jean Brouwers, Aug 6, 2004
    #5
  6. Vote...

    And what is the position from Kerry and/or Bush ?
     
    Michel Claveau - abstraction méta-galactique non t, Aug 6, 2004
    #6
  7. Istvan Albert

    AdSR Guest

    Istvan Albert <> wrote in message news:<>...
    > 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
     
    AdSR, Aug 6, 2004
    #7
  8. Istvan Albert

    Peter Hansen Guest

    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
     
    Peter Hansen, Aug 6, 2004
    #8
  9. 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.
     
    Christopher T King, Aug 6, 2004
    #9
  10. 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:>
    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 +49 30 89 09 53 34 home +49 30 802 86 56 mobile +49 173 24 18 776
    PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
    whom do you want to sponsor today? http://www.stackless.com/
     
    Christian Tismer, Aug 6, 2004
    #10
  11. 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, Aug 6, 2004
    #11
  12. 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?"
     
    Christopher T King, Aug 6, 2004
    #12
  13. On Fri, 06 Aug 2004 08:24:47 -0400, Peter Hansen <> 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/python-dev/2004-August/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).
     
    Anthony Baxter, Aug 6, 2004
    #13
  14. > Please reconsider the "def f() [classmethod]:" construct.

    +1 from me.

    Edward
    --------------------------------------------------------------------
    Edward K. Ream email:
    Leo: Literate Editor with Outlines
    Leo: http://webpages.charter.net/edreamleo/front.html
    --------------------------------------------------------------------
     
    Edward K. Ream, Aug 6, 2004
    #14
  15. Istvan Albert

    Greg Krohn Guest

    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
     
    Greg Krohn, Aug 6, 2004
    #15
  16. ;o)
     
    Michel Claveau - abstraction méta-galactique non t, Aug 6, 2004
    #16
  17. On Fri, 06 Aug 2004 08:24:47 -0400, Peter Hansen <> 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
     
    Bengt Richter, Aug 6, 2004
    #17
  18. Istvan Albert wrote:
    > Voting for the "list-after-def" syntax as shown above:
    >
    > Peter Hansen <>
    > AdSR <>
    > Paul McGuire <._bogus_.com>m
    > Phillip J. Eby pje at telecommunity.com
    > C. Barnes <>
    > Aahz aahz at pythoncraft.com
    > Skip Montanaro skip at pobox.com
    > Bill Janssen janssen at parc.com
    > Istvan Albert


    +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
     
    Reinhold Birkenfeld, Aug 7, 2004
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Delaney, Timothy C (Timothy)

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

    Delaney, Timothy C (Timothy), Aug 6, 2004, in forum: Python
    Replies:
    3
    Views:
    281
    Anthony Baxter
    Aug 6, 2004
  2. Anthony Baxter
    Replies:
    3
    Views:
    299
    Anthony Baxter
    Aug 6, 2004
  3. Paul McGuire
    Replies:
    25
    Views:
    610
    Eli Stevens (WG.c)
    Aug 25, 2004
  4. Robert Brewer
    Replies:
    5
    Views:
    260
    Michael Sparks
    Aug 22, 2004
  5. Robert Brewer
    Replies:
    13
    Views:
    471
    Anthony Baxter
    Aug 26, 2004
Loading...

Share This Page