pep-318 questions

[Skip Montanaro]

    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