[Python-Dev] Re: new syntax for wrapping (PEP 318)

[Jewett, Jim J]

Pete Shinners:
> Some of these may even be bad ideas apon further
> thought, but it's something to ponder.

Also, many of them don't work with the proposed 
syntax.  Specifically, you're trying to provide
a second binding for the function (such as running
for __main__, or registering with the exit handler).

For me, this is the most common use case, but ...
PEP 318 doesn't handle it.  (Which is one reason
that I don't think this will be the *last* extension,
which is one reason I don't want *bare* syntax.)

Skip:
> Quixote'd PTL uses almost this exact syntax to
> distinguish between PTL functions/methods which 
> return HTML or plain text.  The only difference
> is that it places the annotation before the argument
> list:

>    def head [html] (title):

> I haven't heard any Quixote users complain about the
> construct. 

But they do warn you that it doesn't quite work with
standard python.  Nobody comes across this syntax until
they have gone out of their way to expect it.  Even so,
would it be better or worse for them to start finding 
code that says

    def head [classmethod] (title):

I realize that the new syntax (patch version) would 
actually say something more like

    def head [html](title)[classmethod]:

which goes a fair way toward exhausting special syntax.
If they want to get more detailed (xml vs html, only
do this if the user is authenticated, etc), then the
new syntax starts to be useful to them as well.

    def head(title) decorators[html4, authenticated_user]:

Even if the two cases are combined, I don't see it
as useful enough to use up bare syntax.  (And so I
suggest yet another possible keyword, "decorators")

Paul Prescod:

> C# allows the wrapping of attributes, not just 
> functions and classes.

> In Python this could be accomplished if we used 
> delimiters that didn't look like lists (e.g. <> or [! !]).

Do this sort of thing often enough, and you have a
keyword anyhow -- it just happens to look like line noise.

> C# distinguishes between bareword declarations like
> "public" and "int" and metadata attachments like
> XML serialization information.
...
> The Java way does make clear what is a language builtin
> ("public", "void") and what is extension metadata 
> "@remote", "@debug". That may not be a bad thing...

Unless we define a specific list (just classmethod and 
staticmethod?), then this might be more confusing than
useful.  in __builtins__?  In the current standard library?
in another module that might become standard someday?

Skip Montanaro:
> If anything, features which are expected to be used by 
> more advanced users should require less "COBOL" to be 
> useful. I'm not arguing that the zen of Python shouldn't
> apply, just that advanced features (which will probably
> be used a lot less than more basic features) don't 
> necessarily need quite the English-like structure supporting
> them in the language syntax.

Features which are used frequently need to be short.
Features which are used rarely (like this one?) can be 
more verbose.

I agree that if only advanced users will need it, then it
can be a bit more complex to use.  It should absolutely
not be harder to recognize as irrelevant.  

If you use an almost meaningless keyword like 
"extended_syntax_form_a", then the only extra burden is 
on the advanced users who actually use it.  (This is one
reason that I'm not too concerned over *which* keyword 
gets used.)  If you use bare syntax, then the burden is 
on everyone, and you have raised the barrier to entry for 
the rest of the language.

Paul Moore:

> Exactly. As a beginner, classes were more advanced than
> you needed.  So the (relative) difficulty of finding the
> relevant details wasn't an issue - you just didn't use
> the feature for a while. By the time you needed classes,
> you were familiar enough with Python to know where to look.

I have never *needed* classes, and have a bias towards 
functions.  If *functions* had seemed awkward, I would have
chosen another language instead.  People with a bias 
towards objects - or wanting to learn about them - may
well have different criteria.  (In real life, most 
object systems are pretty wordy, so this particular concern 
may not bother OO folk as much.  But the main use cases are
for functions.)

-jJ