pep-318 questions

Discussion in 'Python' started by Hallvard B Furuseth, Aug 8, 2004.

  1. ....and opinions:)

    I don't understand some of the arguments in pep-318 (version 1.19),
    or what the current syntax has to do with some of the design goals
    mentioned there. Could someone explain?

    > Design Goals
    >
    > The new syntax should
    > (...)
    > make it obvious what is happening; at the very least it should be
    > obvious that new users can safely ignore it when writing their own
    > code


    Huh? The current no-keyword, no-indentation syntax seems as far
    removed from "obvious" as one could get for Python.

    As for obvious that new users need not use it, it seems pretty hard
    to _avoid_ meeting that goal. Is it just included for completeness,
    or does it mean something more than I see in the statement?

    > not make it more difficult to scan through code quickly. It should
    > still be easy to search for all definitions, a particular definition,
    > or the arguments that a function accepts


    The current syntax seems like the clear loser here too:
    No whitespace above the function name. Not too bad with a single
    decorator, but several is a problem. In fact, I think decorator-
    before-def scales very badly in this respect, at least the syntaxes
    without indentation. And the way people are coming up with uses for
    decorators, functions could end up with a lot of decorators.

    Quoting Arthur, "Doesn't readibility require that you have the
    ability to move in a direction down the page, and, if so, why am I
    getting information about a method prior to the existence of the
    method, before a proper introduction has been made, i.e. before I
    even know its name."

    Anyway, to me, decorator after the def's ':' seems like the clear
    winner on the "easy to scan" point, decorator before ':' might
    possibly be #2 (unsure here - it's "theoretically right" but some
    posted examples look ugly), and a statement with indentation in
    front of the def #3. (Could indent just the decorators like the
    'using' suggestion in the PEP, see below.)

    > Alternate Proposals


    > using:
    > dec1
    > dec2
    > ...
    > def foo(arg1, arg2, ...):
    > pass
    >
    > The function definition is not nested within the using: block
    > making it impossible to tell which objects following the block
    > will be decorated.


    Huh? How is this different from telling which 'else:' is tied to an
    'if:'?

    It does give the def statement a new syntax in that it can be the
    2nd part of a compound statement. Is that what you mean - that
    people who do not know about decorators won't know they must read
    the 'using:' together with the 'def:'? If so, it seems to me that
    the cure is exactly the same as with the @ syntax: Don't put any
    whitespace between the decorator and the def. If you do put
    whitespace there, both syntaxes lose readers who do not know about
    decorators. And probably some readers who do, as well.

    > Nesting the function definition within the using: block suggests
    > nesting of namespaces that doesn't exist.


    Why, when try:, if:, for: and while: do not?
    True, this surprised me when I learned Python. But when I had
    learned it, I had learned it.

    > Finally, it would require the introduction of a new keyword.


    Actually, I'm wondering about that too. As far as I can see, if a
    statement starts with one word and a colon, then the word is a
    keyword. If so, it would not be ambiguous to allow 'using', 'else'
    and 'try' as variable names. And since they are immediately
    followed by the colon, the parser only needs one lookahead symbol to
    tell that they are keywords. Yet I do see that it might complicate
    the parser somewhat, and allow more bugs or more obscure error
    messages when someone forgets the colon.

    Anyway, '@using:' could be an alternative, even if it has an excess
    of special characters. Or __future__, of course.

    --
    Hallvard
    Hallvard B Furuseth, Aug 8, 2004
    #1
    1. Advertising

  2. Hallvard> I don't understand some of the arguments in pep-318 (version
    Hallvard> 1.19), or what the current syntax has to do with some of the
    Hallvard> design goals mentioned there. Could someone explain?

    The PEP is known to be pretty far out-of-date with both the current patch
    and current thinking. Anthony Baxter and I are the people who have most
    recently edited it, but we are both short on time. I was out of town for
    three days and returned to more than a thousand Python-related mails, most
    dealing with PEP 318. I'm still digging out from that avalanche and have
    yet to even look at the text of the PEP for several days, let alone
    incorporate the wiki page or any of the comments here or in python-dev into
    the text.

    >> Design Goals
    >>
    >> The new syntax should
    >> (...)
    >> make it obvious what is happening; at the very least it should be
    >> obvious that new users can safely ignore it when writing their own
    >> code


    Hallvard> Huh? The current no-keyword, no-indentation syntax seems as
    Hallvard> far removed from "obvious" as one could get for Python.

    I think it's fairly well understood at this point that "obvious" is both in
    the eye of the beholder and difficult to achieve (there's not a large body
    of similar features in enough other languages that most programmers will
    have had experience with). Thankfully, it says "should" instead of
    "must". ;-)

    Hallvard> As for obvious that new users need not use it, it seems pretty
    Hallvard> hard to _avoid_ meeting that goal. Is it just included for
    Hallvard> completeness, or does it mean something more than I see in the
    Hallvard> statement?

    I can take it out if you like. ;-)

    I think the biggest single requirement has to be that any solution adopted
    must be easier to use than the current decorate-after-body scheme:

    def func(a, b):
    blah
    blah
    ... 75 more lines ...
    blah
    return blah
    func = staticmethod(func)

    Thankfully, all proposals I've seen satisfy that requirement.

    Hallvard> The current syntax seems like the clear loser here too: No
    Hallvard> whitespace above the function name. Not too bad with a single
    Hallvard> decorator, but several is a problem.

    There's no requirement that you smash them all together. This is valid with
    the current patch:

    @ a

    # comment
    # comment
    # comment
    # comment
    @ b


    def func(*args, **kwds):
    ...

    Hallvard> Anyway, to me, decorator after the def's ':' seems like the
    Hallvard> clear winner on the "easy to scan" point, decorator before ':'
    Hallvard> might possibly be #2 (unsure here - it's "theoretically right"
    Hallvard> but some posted examples look ugly), and a statement with
    Hallvard> indentation in front of the def #3. (Could indent just the
    Hallvard> decorators like the 'using' suggestion in the PEP, see below.)

    I think Guido pronounced on this over the weekend. He stated that
    decorators don't belong indented with the code, even at the beginning. In
    fact, he commented that in retrospect he feels that doc strings belong
    outside the function as well. (Of course, that would present a practical
    conflict between a module's doc string and that of the first executable code
    in the module file should it happen to be a function definition. But I
    digress...)

    >> Finally, it would require the introduction of a new keyword.


    Hallvard> Actually, I'm wondering about that too.

    Nobody has so far been able to come up with a single keyword that seems to
    connote "this is a decorator function that is to be applied to the next
    function definition".

    Skip
    Skip Montanaro, Aug 10, 2004
    #2
    1. Advertising

  3. Hallvard B Furuseth

    AdSR Guest

    Skip Montanaro <> wrote in message news:<>...
    > <snip>
    > I think Guido pronounced on this over the weekend. He stated that
    > decorators don't belong indented with the code, even at the beginning. In
    > fact, he commented that in retrospect he feels that doc strings belong
    > outside the function as well. (Of course, that would present a practical
    > conflict between a module's doc string and that of the first executable code
    > in the module file should it happen to be a function definition. But I
    > digress...)


    The nice thing about the @decor syntax is that it might be easy to
    extend it to @"""Docstring""" - "decorate" a function (or class) with
    the docstring if the decorator expression is a string literal instead
    of an expression.

    I prefer in-body docstrings though. While function decorators should
    be well visible - they may do important changes to function's behavior
    - the docstring is of secondary importance, only needed when we don't
    know/remember what the function/class does (and hence should also fold
    easily in a folding editor).

    > <snip>
    > Nobody has so far been able to come up with a single keyword that seems to
    > connote "this is a decorator function that is to be applied to the next
    > function definition".


    And '@' does good job of it - it stands out well. Plus, it's a
    decorated 'a' in many fonts :)

    AdSR
    AdSR, Aug 10, 2004
    #3
  4. Sorry with the late reply; when I got back to clp I had the silly idea
    that I'd try to catch up with the decorator threads before answering...
    Anyway,

    Skip Montanaro wrote:

    > Hallvard> The current syntax seems like the clear loser here too: No
    > Hallvard> whitespace above the function name. Not too bad with a single
    > Hallvard> decorator, but several is a problem.
    >
    > There's no requirement that you smash them all together. This is valid with
    > the current patch:
    >
    > @ a
    >
    > # comment
    > # comment
    > # comment
    > # comment
    > @ b
    >
    >
    > def func(*args, **kwds):
    > ...


    Which is even worse because one can easily miss some of the decorators
    after locating the function.

    > >> Finally, it would require the introduction of a new keyword.

    >
    > Hallvard> Actually, I'm wondering about that too.
    >
    > Nobody has so far been able to come up with a single keyword that seems to
    > connote "this is a decorator function that is to be applied to the next
    > function definition".


    I thought the main objection to a keyword is that it breaks existing
    code; I wasn't talking about _which_ keyword to choose.

    My point is that maybe the J2 syntax does _not_ need to be a keyword.

    It should work to recognize statements that begin with one word and a
    colon, and treat that word as a pseudo-keyword in that statement. As
    far as I can tell, that does not break anything: A valid statement
    cannot begin with a non-keyword followed by a colon today.

    That also makes 'apply' a candidate for the... pseudo-keyword, if anyone
    still wants that one.

    And if anyone wanted to, one could make 'else', 'try' and 'finally'
    into non-keywords so they could be used as variables:)

    --
    Hallvard
    Hallvard B Furuseth, Aug 28, 2004
    #4
    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. John Roth

    PEP 318 - PyFIT comments

    John Roth, Aug 4, 2004, in forum: Python
    Replies:
    7
    Views:
    365
    Nick Vargish
    Aug 6, 2004
  2. Edward K. Ream

    Confused about pep 318

    Edward K. Ream, Aug 4, 2004, in forum: Python
    Replies:
    45
    Views:
    958
    Shalabh Chaturvedi
    Aug 6, 2004
  3. Delaney, Timothy C (Timothy)

    RE: Decorator syntax (was Re: PEP 318 - PyFIT comments)

    Delaney, Timothy C (Timothy), Aug 5, 2004, in forum: Python
    Replies:
    16
    Views:
    553
    =?ISO-8859-1?Q?I=F1igo?= Serna
    Aug 6, 2004
  4. Tim Hochberg
    Replies:
    0
    Views:
    269
    Tim Hochberg
    Aug 10, 2004
  5. Arien Malec

    PEP 318 decorators are not Decorators

    Arien Malec, Aug 13, 2004, in forum: Python
    Replies:
    11
    Views:
    562
    Arien Malec
    Aug 16, 2004
Loading...

Share This Page