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

[Bob Ippolito]

On Feb 26, 2004, at 2:12 PM, Jewett, Jim J wrote:

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

If the decorator were deemed useful enough, it would be part of the 
standard library of Python 2.5 (or whatever).  I don't see the 
reasoning in your argument:
* This new syntax lets us make common idioms easier
* But we also need to add a new function to the standard library in 
order to make that particular idiom truly easier
* So the new syntax sucks

Nothing is stopping you from sticking with Python 2.3 for the rest of 
your life ;)

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

Well migrating to the new syntax entirely will eventually take us from 
N compilers for domain specific python-like languages, to ~1 compiler 
because Python will be better at domain specific languages.  I think 
this is reason enough, even without the staticmethod/classmethod 
usages.

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

Chances are, HyperMetaConfusing will use decorators in its own source 
code, but not require them from the API.

> 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 prefer to use instances to save state, not classes :)

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

It doesn't have any bearing on any existing code whatesoever (except 
potential for cleanup of the nasty stuff that uses decorators now), and 
you really just don't have to learn it for a while unless it becomes so 
popular that everyone uses it for everything (doubtful).  Then again, 
I'm not trying to teach anyone python, nor am I trying to learn python 
basics.  If you want a reduced Python syntax to teach with, give them 
Python 1.5, and save the good stuff for people who need to get stuff 
done ;)

-bob