pep-318 questions

[Hallvard B Furuseth]

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