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