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

[Bob Ippolito]

On Feb 26, 2004, at 11:35 AM, Jewett, Jim J wrote:

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

Sorry, but you understate the capabilities of this new syntax and 
overestimate the need for future related syntax.  Try the following 
decorators in the current Python interpreter, using the clumsy def 
foo(): ... foo = decorator(foo) pattern:

def mainfunction(fn):
     # some more elaborate mechanism to make this happen when the module
     # is fully loaded is an exercise for the reader, but should be 
altogether possible
     # peak.util.imports would be a good inspiration for this
     if fn.__module__ == '__main__':
         fn()
     return fn

import atexit
def onexit(fn):
     atexit.register(fn)
     return fn

> 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")

I don't want to argue these points specifically, however, in theory the 
proposed new syntax is enough to accommodate Quixote's domain specific 
language **without the need for a custom grammar**.  Therefore, garbage 
like "def head[html](title)[classmethod]" just wouldn't happen.  It 
would simply be a transition of "def head [html](title)" to whatever it 
would be called with the new syntax, whenever that is decided.

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

The problem is that advanced users will need it /quite/ frequently :)  
Advanced users can already *do* all these things, but it's clumsy 
enough to make them want to use some other language or grammar to do it 
with (examples of this have been extensively covered).

I don't think it's a burden on the rest of the language, I just think 
it's a burden on newbies who try and read advanced code.  They'll 
probably be confused by what it does, anyway.

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

Classes are currently so much more preferable to functions because it's 
easier to make them carry around lots of beautiful wonderful metadata.  
When you use metadata (and metaclasses, and descriptors) properly, it 
means less boiler-plate code.  This new syntax supports the addition of 
metadata, reduction of boiler-plate code, and makes creating 
descriptors painless.  Of course, we can already do all these things 
right now with awfully clumsy and unreadable verbose syntax, but it's 
bad enough to where I would want to use another programming language or 
a preprocessor that could expand macros.  Additionally, this new syntax 
will also allow us to remove scary stack introspection hacks that have 
actually *made it into production code*, because it's too inconvenient 
to use explicit metaclasses everywhere you want metadata on classes 
(f.ex., this class provides these interfaces, its instances provide 
these interfaces, etc.).. among other things.

-bob