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

[Jewett, Jim J]

Jim Jewett:
>> 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.)

Bob Ippolito:
> Sorry, but you understate the capabilities of this new
> syntax and overestimate the need for future related syntax.  

Not really; I guess I should have left in the full original 
example.

	def foo[__main__]: 

will not work.

Yes, you can first define a decorator function specific to
this particular function you're about to define, just as you 
can currently rebind the functions's name to a transform of
the function.  Both are ugly.

Jim Jewett:
>> I realize that the new syntax (patch version) would
>> actually say something more like [for Quixote]

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

Bob Ippolito:
> in theory the proposed new syntax is enough to accommodate
> Quixote's domain specific language **without the need for a
> custom grammar**. 

Agreed.  If it weren't for backwards compatibility, they could
just migrate to the new version entirely.  My point isn't that
both are needed; my point is that using up unnamed syntax can
come back to bite you later.  (In fairness, this is also a
slight knock against "as", which could just as easily mean
"alias" - which I find a more common use case.  But "as" is
OK if the proponents really want something short.)

Jim Jewett:
>> 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.

Bob Ippolito:
> The problem is that advanced users will need it /quite/ 
> frequently :)  

Fair enough; then it is reasonable to use an obscure 
abbreviation, so long as it isn't obscure enough to
be mistaken for possibly normal usage.  Use "X" as the
magic keyword if you want.  (Though even "as" is better.)

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

I haven't seen much in the way of difficulty-graded
indices of sample code.  A common introduction to a new
language is to have a specific problem, and to hear that 
package X solves it.  If package HyperMetaConfusing is 
the package that solves the problem, then it is the first 
package new users will look at.

Jim Jewett:
>> If *functions* had seemed awkward, I would have
>> chosen another language instead.

Bob Ippolito:
> Classes are currently so much more preferable to
> functions because it's easier to make them carry
> around lots of beautiful wonderful metadata.  

For me, the advantage is that they save state.

I understand that others use them very differently;
my main point is that adding syntax to something I
consider crucial (functions) is more of a problem
(for me) than adding it to something that I don't
consider crucial.

If this transform applied only to class methods, it
would not have put newbie-me off, because those aren't 
as basic.  (I don't suggest this artificial distinction;
I only point out that it affects the "cost" of the
change.)

I am willing to bet that most programmers (and non-
programmers starting with python as a first language)
will believe that they need to learn functions.  So
function syntax should be as transparent as possible.

-jJ