Confused about pep 318

[Michael Hudson]

Indeed, pep 318 is grossly misleading;

PEP 318 has a slightly sorry history. As far as I can remember, it
was written as an attempt to promote a specific syntax proposal (the
'as' variant? Maybe, it's not really important). Since then it's
been co-opted to be "The Decorators Pep" and received various rounds
of rewrites, none of which have pleased everyone (surprised? with
this topic). I belive it's fair to say that PEP 318 has *never*
accurately reflected the state of play on this issue.

This is unfortunate, yes. The idea that the process goes from pep to
discussion back to pep to implementation is a nice one, but not really
how it happens, for better or worse.

Cheers,
mwh

 

[Peter Hansen]

FFS. What exactly is "Perlish" about @? It's an unused symbol. That's all.

"For Fucks Sake", presumably? Sorry you're feeling pressured by this...

Anyway, that is exactly what is Perlish about it. Perl takes pretty
much every unused symbol and finds some completely arbitrary way
to use them, just because they are there. So far, Guido has
avoided that (almost?) entirely in Python, using symbols that
have very well-established meanings in other computer languages and
even outside of the computer realm itself (e.g. the use of colon).

It surprises me that he didn't discard this choice out of hand.

I'm also surprised that the choice which had the greatest public
support during the straw poll at PyCon isn't still under discussion,
but I readily admit I'm neither following nor participating in
the pydev discussions where it was presumably dropped for some valid
reason...

-Peter

 

[Peter Hansen]

FFS. What exactly is "Perlish" about @? It's an unused symbol. That's all.
It's hardly arbitrary - Java, for instance, already uses @ for the same thing.

And Java chose it based on what precedent? Basing a choice on
someone else's arbitrary choice makes something only ever so
slightly less arbitrary.

Python doesn't need to select syntax from other languages. Python
leads, it doesn't follow. Until now. :-(

-Peter

 

[Michael Hudson]

Python doesn't need to select syntax from other languages. Python
leads, it doesn't follow. Until now. :-(

Say what?

Cheers,
mwh

 

[Edward K. Ream]

Sorry, but if discussions on python-dev are not considered "public", what
is?

The reason that discussions on py-dev were not valid a public discussion of
'@' is that there was no public announcement that pep 318 pertained to '@'.
It's that simple.

It's sorta like holding a public meeting supposedly to discuss sewers and
voting to give all the county commissioners 100% raises instead The
public wasn't informed of the true nature of the meeting, so the open
meeting law was violated.

To repeat: given that pep 318 is grossly misleading, I contend that no
proper discussion of it has ever taken place. Sorry, but if you actively
mislead the public, then the public _does_ have a right to complain. The
web is a huge place. Expecting people to track it without proper notice of
what is being discussed is patently unfair.

Edward

 

[Ville Vainio]

Anthony> FFS. What exactly is "Perlish" about @? It's an unused
Anthony> symbol. That's all. It's hardly arbitrary - Java, for
Anthony> instance, already uses @ for the same thing.

The problem with @ as I see it (FWIW, of course) is that the new
syntax wastes @ for a minor feature. I wouldn't mind @[decorator],
which would allow reserving stuff like @private (compiler / type
inferrer / macro / whatever) for future extension of the language.

And "def decorator func(args):" is even worse. Most interesting
applications of decorators involve decorators with arguments...

 

[Terry Reedy]

That thread reaches no consensus,

To me this is evasion.
looking.

That's because it was. ...
There had previously been no public discussions about it.

You (agreeing with Steven) made a false accusation of something like
dastardliness. Just admit your mistake and move on.

I happen to sympathize with some of you concerns and suggestions, but not
with needless bashing of volunteers.

other than, in his sole post in the thread, Guido stating
"I would love to see an implementation of this idea."

Hence, I was not surprised to see it in an alpha as an experimental feature
which might or might not stay.

Terry J. Reedy

 

[Christopher T King]

To me this is evasion.

Well, it is.

You (agreeing with Steven) made a false accusation of something like
dastardliness. Just admit your mistake and move on.

(More evasion +10 points for using the word "dastardliness" in a
sentence. +10 more for using it legitimately in a post on a computer
language mailing list.

Hence, I was not surprised to see it in an alpha as an experimental feature
which might or might not stay.

Indeed, I was comforted by a recent post of Guido's in python-dev:

When I let Anthony check it in for 2.4a2, the plan was to see how it
fares in a2 and a3, and possibly take it out in 2.4b1.

I was afraid that going in so close to 2.4b1, @ was in for good, but
knowing they may yet come out is good.

 

[Terry Reedy]

The issue is not about rights to commit code, the issues are whether

a) the question was ever publicly discussed at all and

Deorators have been discussed on PyDev at least since Jan 03. The @ syntax
was introduced there in June04 with AB's post starting this thread:
http://mail.python.org/pipermail/python-dev/2004-June/thread.html#45516

b) whether any consensus was reached.

My impression as a mostly lurker who sees no immediate personal use for
decos is that there was a partial consensus on the desirability of
something, but not on the syntax. The 'tie-breaking' procedure is Guido
decides, and so, with 2.4 looming, he did, at least as an experiment.

this.

Not nice. Essential. It is fundamentally unfair to pretend to have
discussed a proposal publicly that has always been grossly misrepresented in
the one place one would naturally look to find information about it.

Perhaps in this case the PSF should have paid someone to keep it updated
better. The problem I see is that most strong advocates of some deco
syntax also had a favorite syntax and were not candidates writing an
even-handed treatment of options.

Terry J. Reedy

 

[Terry Reedy]

Sorry, but if discussions on python-dev are not considered "public", what is?
It's an open list, with publically available archives.

For those who prefer a newgroup interface, for the selective download into
a separate box, gmane.org carries it as comp.lang.python.devel. Also,
Brett Cannon's summaries have been posted here on c.l.py for nearly two
years, with references to the appropriate threads in the archives.

Terry J. Reedy

 

[Tor Iver Wilhelmsen]

And Java chose it based on what precedent?

It's own: It follows from their existing use in JavaDoc tags. Already,
some preprocessors (like one for DBC) used "custom" tags using this
syntax, though still inside JavaDoc comment blocks. Other extensions,
like Microsoft's J/Direct used for their deviating Java VM, also used
the syntax.

The new Java2SE 5.0 / JRE 1.5.0 annotations syntax puts them around
where their C# equivalent metadata mechanism is.

E.g. J2SE 5.0:

@ImplementsRequirement("B2")
public void adjustPrices(ArrayList<Price> prices) {
//...
}

C# 2.0 (for the generics):

[ImplementsRequirement("B2")]
public void AdjustPrices(ArrayList<Price> prices) {
// ...
}

 

[Bengt Richter]

Hello all,

[... snip admirably restrained post ..]
I too am very much against wasting '@' on @decorator!
Please see my post in the "tweaking @decorator syntax" thread
for a possible alternative that might also have some interesting
room for inventive use.

Regards,
Bengt Richter

 

[Steven Bethard]

Not a big fan of this syntax -- no intuitive reason why @ would mean
decorator -- but I presume this has already been complained about...
Could someone direct me to the discussions about this? I'd like to
see why it was the eventual favored syntax...

So, I did my homework and read way too much python-dev for a mere
mortal, and found a good synopsis that is worth looking at if you
haven't already:
http://www.python.org/moin/PythonDecorators
It gives a bunch of the different considered syntaxes, pros and cons,
etc.

I have to say, after reading the archives and the wiki, I like @ a
little bit more. The other major frontrunners I saw were a
list-before-def syntax and a function-call-before-def syntax. Both of
these have the major flaw that they take currently valid Python code
and give it a different meaning. I don't like that -- it means I have
to relearn part of Python semantics. Even the list-after-def syntax,
which doesn't introduce semantics changes, isn't substantially clearer
to me as a decorator than @ is -- why is a list before the : a list of
decorators? Seems almost as arbitrary as @.

What would have seemed most Pythonic to me is a new keyword -- like
was done for 'yield' -- but that seems to have been voted down.
(Guido especially dislikes the use of 'as' for these purposes.) I'd
still prefer a new keyword over @, but if a new keyword is out of the
question, I'll take @ over any syntaxes that change Python's current
semantics, and I'll take an implemented and working @ over an as-yet
unimplemented list-after-def syntax.

Steve

 

[Anthony Baxter]

The problem with @ as I see it (FWIW, of course) is that the new
syntax wastes @ for a minor feature. I wouldn't mind @[decorator],
which would allow reserving stuff like @private (compiler / type
inferrer / macro / whatever) for future extension of the language.

See, that's a matter of opinion. I don't think decorators will end up
being a "minor feature". I think they have the potential for much
interesting meta-programming. I also don't think that hanging onto
a particular ascii glyph for "some future use" is particularly useful -
I'm not aware of any other potential use for this. Unless we use
it to indicate an array <wink>.

 

[Skip Montanaro]

Michael> PEP 318 has a slightly sorry history. As far as I can
Michael> remember, it was written as an attempt to promote a specific
Michael> syntax proposal (the 'as' variant? Maybe, it's not really
Michael> important). Since then it's been co-opted to be "The
Michael> Decorators Pep" and received various rounds of rewrites, none
Michael> of which have pleased everyone (surprised? with this topic).
Michael> I belive it's fair to say that PEP 318 has *never* accurately
Michael> reflected the state of play on this issue.

Thank you. As one of the people who have rubbed PEP 318 around in the dirt
a bit I think what you wrote about sums up its state. I realize that Guido
discussed decorator syntax at EuroPython. A good take-away from that would
have been for someone involved in those discussions to take an action item
to update the PEP.

Skip

 

[Anthony Baxter]

To repeat: given that pep 318 is grossly misleading, I contend that no
proper discussion of it has ever taken place. Sorry, but if you actively
mislead the public, then the public _does_ have a right to complain. The
web is a huge place. Expecting people to track it without proper notice of
what is being discussed is patently unfair.

"Actively mislead the public"? What the hell is that supposed to mean?
Look, you keep insinuating that there was some sort of evil plot to slip
this into Python. I can assure you that this is NOT true, and I'm getting
more than a little bit fed up with this argument.

This feature was put into a2 because Guido's judgment was that it
was appropriate to do so. The whole _point_ of an alpha cycle is that
we can try things out, and we don't have to be backwards compatible
if it turns out to have been a bad decision.

As I've stated, _repeatedly_, yes, it would have been better had the PEP
been kept up to date. This didn't happen, but people are working on this.

 

[Skip Montanaro]

Bengt> I too am very much against wasting '@' on @decorator!

We could just switch completely to Unicode. Then we'd have all sorts of
punctuation characters available. How about

# -*- coding: utf-8 -*-
\xe2\x98\xbadecorator
def f():
pass

?

Skip

 

[Aahz]

"Actively mislead the public"? What the hell is that supposed to mean?
Look, you keep insinuating that there was some sort of evil plot to
slip this into Python. I can assure you that this is NOT true, and I'm
getting more than a little bit fed up with this argument.

I'm not reading Edward as claiming the existence of an evil plot. OTOH,
"actively mislead" is certainly an overstatement, *except* WRT the claim
you're making that there was public discussion of the @ syntax going into
Python. I think Edward's got a fair point there.

Also, there has historically been an expectation that PEPs will be
posted to comp.lang.python in their final draft form; while I agree with
you that python-dev is a public forum, I think the outrage expressed by
those who believed that they didn't *NEED* to monitor python-dev is
entirely understandable.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"To me vi is Zen. To use vi is to practice zen. Every command is a
koan. Profound to the user, unintelligible to the uninitiated. You
discover truth everytime you use it." (e-mail address removed)

 

[Anthony Baxter]

Also, there has historically been an expectation that PEPs will be
posted to comp.lang.python in their final draft form;

That's news to me, although I think it's probably a good idea.

while I agree with
you that python-dev is a public forum, I think the outrage expressed by
those who believed that they didn't *NEED* to monitor python-dev is
entirely understandable.

I'm not sure what additional benefits would have come from some more
advance notice of this to c.l.py, in addition to python-list.

I don't think the outrage would have been any less from the people
who _really_ don't like the feature. The folks who just don't think
decorators belong in the language, in any form, can hardly have
missed the frequent mentions in Brett's python-dev summaries.

Additionally, anyone who has a great alternative still has time to get
their idea in instead of the @syntax. If anything, the availability of the
current form in a released (alpha) of Python makes it easier for people
to actually play with it and see what they think - this is something that's
much harder to do from a proposal.

 

[Erik Max Francis]

Bengt> I too am very much against wasting '@' on @decorator!

We could just switch completely to Unicode. Then we'd have all sorts
of
punctuation characters available. How about

# -*- coding: utf-8 -*-
\xe2\x98\xbadecorator
def f():
pass

?

Given how things are looking so far with the reaction to the decorator
syntax, I'd say U+2639 might be more appropriate ...