Confused about pep 318

[Edward K. Ream]

Hello all,

First of all, my present state of mind re pep 318 is one of sheepish
confusion. I suspect pep 318 will not affect Leo significantly, but I am
most surprised that an apparently controversial feature is being added
without a notice, say, in comp.lang.python.announce. I say sheepish,
because everyone knows that one should make sure new proposals don't bite
you. Still, I would have thought that there were other ways of keeping
abreast of potentially major changes to Python besides reading py-dev...

The following are some comments to recent posts on py-dev. I hope to convey
by these remarks my sense of bewilderment.

There is little point in going over all the same arguments again and again. For this alpha release, no amount of arguing will change what has
been committed. You really have to organize a public outcry if you want the
syntax changed before 2.4. [Martin v. Löwis]

I'd like to defer the question of a "public outcry" until later, hopefully
much later.

But I have no idea what the proposed syntax is(!!) In particular, there is
no mention of '@' directly on the page
http://www.python.org/peps/pep-0318.html

Is there a summary of recent work? An announcement? Some indication of
consensus?

In general, I predict most Python code will continue to be blissfully

unadorned with decorators.
Right. Outside the test suite, there are very few uses of classmethod, staticmethod and property in the standard library. GvR

Hmm... I see nowhere in pep 318 any mention that the pep will affect the
following section of the Reference manual:
http://docs.python.org/ref/delimiters.html

[quote]
The following printing ASCII characters are not used in Python. Their
occurrence outside string literals and comments is an unconditional error:
@ $ ?
[end quote]

I would regard any change to this paragraph as a major change to Python, in
spite of its innocent appearance. Indeed, this paragraph is an excellent
"line in the sand" for other tools.

To repeat, I suspect adding @ would not affect Leo significantly in any
direct way, and a workaround would probably exist even if it did. However,
this proposal probably would affect the noweb markup language on which Leo
is (loosely) based. See http://www.eecs.harvard.edu/~nr/noweb/

BTW, a long while back I suggested that there was no reason for the parser
to need colons after "if" statements, etc. The response was: true, but
allowing colons to be elided would impact existing tools. So I gave up. Am
I the first to suggest that allowing '@' characters in valid Python programs
outside string literals and comments might negatively impact existing tools?
Sigh. This discussion is going around in pointless circles; we're *months* past that point. You're wasting your time (and mine). [GvR]

I confess that I don't understand this remark at all. How has it happened
that so many people are confused about this proposal? And if everything is
so clear, why isn't the clarity reflected in pep 318 itself?

http://www.python.org/peps/pep-0318.html talks about

- Background
- Design goals
- Proposed syntax (no mention of @!)
- Alternative proposals
etc.

Excuse me, but if everything is now set in stone, then this is an
extraordinarily misleading document.
Sorry. I think you'd be wise to consider the months without consensus as

evidence of a problem. [Jim Fulton]

This is my present opinion as well.

Summary

I wish to disavow any knowledge, or any interest in, the wider issues of
whether pep 318 is a good idea or not. My concern is exclusively with the
following two issues:

1. IMO, allowing '@' in valid Python programs (outside string literals or
comments) is a major change to the language that has significant potential
to disrupt already existing tools. At the very least, some discussion of
http://docs.python.org/ref/delimiters.html should be in pep 318.

2. pep 318 apparently does not reflect the present state of affairs, and
afaik there has been no announcement of proposed changes on
comp.lang.python.announce. This is disturbing. If anyone could clarify the
present status of pep 318 I would be most grateful. I would prefer not to
be told to read all the py-dev archives. If everything is now clear, where
can I find out about it?

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Skip Montanaro]

Edward> But I have no idea what the proposed syntax is(!!) In
Edward> particular, there is no mention of '@' directly on the page
Edward> http://www.python.org/peps/pep-0318.html

Anthony Baxter said yesterday on python-dev he was going to attend to that
shortly. As in many other software efforts, the code has moved along a bit
faster than the documentation (after all, what's more fun to do?). I
believe the only significant differences from a pure functional
documentation standpoint to apply to the PEP are the syntax and the issue of
decorated classes (I don't think support for decorated classes will make
it). By way of parallel examples here's how the new syntax corresponds to
the syntax I used in the last revision of the PEP:

#1 from the PEP: Given this function:

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

the new syntax will be:

@onexit
def func():
...

#4 from the PEP: Given these functions:

def accepts(*types):
def check_accepts(f):
assert len(types) == f.func_code.co_argcount
def new_f(*args, **kwds):
for (a, t) in zip(args, types):
assert isinstance(a, t), \
"arg %r does not match %s" % (a,t)
return f(*args, **kwds)
return new_f
return check_accepts

def returns(rtype):
def check_returns(f):
def new_f(*args, **kwds):
result = f(*args, **kwds)
assert isinstance(result, rtype), \
"return value %r does not match %s" % (result,rtype)
return result
return new_f
return check_returns

the new syntax will be:

@accepts(int, (int,float))
@returns((int,float))
def func(arg1, arg2):
return arg1 * arg2

I believe the order of application of the above decorators would be like so:

func = accepts(int, (int, float))(returns((int, float))(func)

Edward> I confess that I don't understand this remark at all. How has
Edward> it happened that so many people are confused about this
Edward> proposal? And if everything is so clear, why isn't the clarity
Edward> reflected in pep 318 itself?

There was a lot of discussion on python-dev, but none very recently (last
month or so). Guido indicated there that he brought up the topic at
EuroPython in his keynote talk and entertained discussion from the floor.
Based upon that discussion he decided to go with the @-decorator syntax.
Since EuroPython most/all the discussion went on in private email or on
irc. I think it would be nice if this conversation was summarized in the
PEP, but that will have to come from one of the participants.

Skip

[Edward K. Ream]

> As in many other software efforts, the code has moved along a bit

faster than the documentation (after all, what's more fun to do?). .... Guido indicated there that he brought up the topic at
EuroPython in his keynote talk and entertained discussion from the floor.
Based upon that discussion he decided to go with the @-decorator syntax.
Well, this isn't good. We are talking about a basic design document here.
I feel like I have been kept in the dark; my previous relative silence is
hardly evidence of my agreement. How is it possible to pretend that people
agree with a proposal that DOES NOT EXIST? I am -10 on pep 318 now: this
process amounts to a rigged election. I might become neutral in the future
once the hood is removed from over the candidate's head :-)
I believe the only significant differences from a pure functional
documentation standpoint to apply to the PEP are the syntax

Why is something "spectacular" like the '@' sign is needed? Presumably
there is some problem with the compiler? Has anyone suggested something
like:

from __future__ import annotation as annotate

annotate.accepts(int, (int,float))

instead of:

@accepts(int, (int,float))

Clearly, with enough work the Python compiler could recognize this. Yes,
it's a special case, but so what? This would avoid most problems with
reserved words or keywords. And it would be in the spirit of letting
modules encapsulate most major features.

Edward

P.S. The more I think of this proposal, the more unhappy I become. In fact,
this proposal may have a most unfortunate effect on Leo's future, for two
reasons:

1. Although Leo handles constructs like @accepts, it does so by generating
lines like this:

#@verbatim
@accepts(int, (int,float))

So _Leo_ has no problem, but Leo's users will likely complain that more
cruft has been added to their files.

2. Leo presently supports the following directives:

@ (followed by one or more whitespace characters)
@all, @asis,
@c, @code, @color, @comment,
@delims, @doc,
@encoding, @end_raw,
@file, @first,
@header,
@ignore,
@killcolor,
@language, @last, @lineending,
@nocolor, @noheader, @noref, @nosent, @nowrap,
@others,
@pagewidth, @path,
@quiet,
@raw,
@root, @root-code, @root-doc,
@silent,
@tabwidth, @terse, @thin,
@unit,
@verbose,
@wrap

Worse, Leo allows plugins to define their own directives. There is already
a plugin that defines @wiki. Furthermore, @run, @test and @suite are also
used in special contexts.

What happens when another Python @x construct conflicts with one of these
directives or some other directive? I'm starting to wonder whether Python
is a snake or a gorilla :-)

Yes, Python does have the right to use '@'. But I would hope that GvR would
choose not to do so. I was always under the impression that the clear
statement in the Reference Manual that at signs are invalid everywhere
(except in comments and strings) was a clear signal of an intention to keep
those symbols for other valid purposes. I am extremely unhappy that this
may not be so.

P.P.S. I did respond earlier to the requested survey, saying in brief that
I had no problems with 318 provided that '@' signs did not become a part of
the syntax. I have received no reply from anyone. There is no way somebody
could construe my previous statements as approval.

EKR
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Michele Simionato]

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma**************************************@pyt hon.org>...

There was a lot of discussion on python-dev, but none very recently (last
month or so). Guido indicated there that he brought up the topic at
EuroPython in his keynote talk and entertained discussion from the floor.
Based upon that discussion he decided to go with the @-decorator syntax.
Since EuroPython most/all the discussion went on in private email or on
irc. I think it would be nice if this conversation was summarized in the
PEP, but that will have to come from one of the participants.

Skip

I think the way the decision came up was absolutely unfair to the PEP
proponents and to the Python community at large. This disturb me more
than the syntax itself (which I don't like, but this not the point).
I agree that Guido is the Dictator For Life, but he is supposed to
be Benevolent!

I-will-never-submit-a-PEP-ly,

Michele Simionato

[Steven Bethard]

Skip Montanaro <sk**@pobox.com> wrote in message news:<ma**************************************@pyt hon.org>...

the new syntax will be:

@onexit
def func():
...

Wow, this one really feels like it was slipped in while no one was
looking. While I don't go to Python conferences, I do occasionally
check python-dev, and I totally missed whatever thread introduced the
@ syntax. Scary...

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

Steve

[Christopher T King]

On 5 Aug 2004, Steven Bethard wrote:

Wow, this one really feels like it was slipped in while no one was
looking.
That's because it was.
While I don't go to Python conferences, I do occasionally
check python-dev, and I totally missed whatever thread introduced the
@ syntax. Scary...
This is the post that started it all:
http://mail.python.org/pipermail/pyt...st/046599.html

Quote:
The @decorator patch has been landed on the trunk, after
getting the go-ahead from the BDFL. I'll update PEP-0318
with the final syntax in the next day or so.

That's the first most people had heard of it. Guido had given Anthony
Baxter the go-ahead in a private e-mail. There had previously been no
public discussions about it.
Not a big fan of this syntax -- no intuitive reason why @ would mean
decorator -- but I presume this has already been complained about...

It has, but the more people complaining, the better, if you're against it.

[Anthony Baxter]

On Thu, 5 Aug 2004 12:12:59 -0400, Christopher T King <sq******@wpi.edu> wrote:

This is the post that started it all:
http://mail.python.org/pipermail/pyt...st/046599.html

Quote:
The @decorator patch has been landed on the trunk, after
getting the go-ahead from the BDFL. I'll update PEP-0318
with the final syntax in the next day or so.

That's the first most people had heard of it. Guido had given Anthony
Baxter the go-ahead in a private e-mail. There had previously been no
public discussions about it.

Nonsense.

http://mail.python.org/pipermail/pyt...ead.html#45516
was over a month earlier. In addition, the particular SF item for this
http://www.python.org/sf/979728 wasn't exactly hidden.

Anthony

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

http://mail.python.org/pipermail/pyt...ead.html#45516
was over a month earlier.
That thread reaches no consensus, other than, in his sole post in the
thread, Guido stating "I would love to see an implementation of this
idea." Nothing about "this is going to be in 2.4a2, anybody vehemently
opposed to it?" Like I said, the go-ahead was given privately.
In addition, the particular SF item for this
http://www.python.org/sf/979728 wasn't exactly hidden.

Indeed; I'm surprised it isn't titled "Beware of the Leopard".

[Anthony Baxter]

> > http://mail.python.org/pipermail/pyt...ead.html#45516

was over a month earlier.

That thread reaches no consensus, other than, in his sole post in the
thread, Guido stating "I would love to see an implementation of this
idea." Nothing about "this is going to be in 2.4a2, anybody vehemently
opposed to it?" Like I said, the go-ahead was given privately.

None of the decorator discussions _ever_ reached a conclusion. As mwh put it,
"bike-shed-the-ultimate". At the end of the day, Guido's the one who makes
these decisions. His decision was that the @ syntax should go into 2.4a2.

As far as "private go-ahead", I've lost count of the number of people who
seem to think that this is somehow an issue. Would the bitching have been
seriously that much better if, half an hour before I committed the patch,
Guido had posted a note saying pretty much what I forwarded on from him?
If so, why? Guido followed up to my note pretty much straight away confirming
it. Or would it have someone been better if Guido had done the CVS commit?

Yes, it would have been nice if PEP-0318 was updated in advance of this. I
made an effort, but have run out of resources to work on it. If no-one else
gets to it before me, I will work on it again next week. But, suprise, Python's
a volunteer effort. No-one's paying me to do this, or Guido, or anyone else.
If someone wants to offer to pay me, or someone else, to actually do all this,
*great*.

[Peter Hansen]

Anthony Baxter wrote:

But, suprise, Python's
a volunteer effort. No-one's paying me to do this, or Guido, or anyone else.
If someone wants to offer to pay me, or someone else, to actually do all this,
*great*.

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

-Peter

[Edward K. Ream]

> > There had previously been no public discussions about it.

Nonsense.

I could not disagree more. Pretending that discussions on py-dev and
SourceForge count as truly public discussions of pep 318 is most unwise.
pep 318 does not discuss '@' at all. People like me, with a strong interest
in how Python uses '@', would not naturally have known about the proposed
new syntax until the stuff hit the fan.

Indeed, pep 318 is grossly misleading; reading it one gets the distinct
impression that the design is far from complete. It is my strong opinion
that _no_ public discussion of this new code has taken place, and none _can_
take place until we see what it is exactly that is being proposed. This is
an issue of basic fairness and openness. I have complained loudly to the
[b]DFL. We shall see...

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Anthony Baxter]

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

That thread reaches no consensus, other than, in his sole post in the
thread, Guido stating "I would love to see an implementation of this
idea." Nothing about "this is going to be in 2.4a2, anybody vehemently
opposed to it?" Like I said, the go-ahead was given privately.

None of the decorator discussions _ever_ reached a conclusion. As mwh put it,
"bike-shed-the-ultimate". At the end of the day, Guido's the one who makes
these decisions. His decision was that the @ syntax should go into 2.4a2.

I can't speak for everybody, but I would've liked some closure on the
issue before it was injected into 2.4a2. From what I can tell, in the
public's mind, the syntax of decorators was still an open issue, and if
anything was going to make it in, it was going to be the "def foo()
[dec]:" syntax that was currently in favour. No-one was prepared for the
introduction of the @ syntax.

[Anthony Baxter]

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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.

[Anthony Baxter]

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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

[Anthony Baxter]

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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.

[Anthony Baxter]

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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

[Edward K. Ream]

> None of the decorator discussions _ever_ reached a conclusion.

I find this oddly reassuring, in a sorta black-humorous way. At least we
won't have to undo the previous agreement :-)

Would the bitching have been
seriously that much better if, half an hour before I committed the patch,
Guido had posted a note saying pretty much what I forwarded on from him?
The issue is not about rights to commit code, the issues are whether

a) the question was ever publicly discussed at all and
b) whether any consensus was reached.

Apparently, the answer to both questions is No.
Yes, it would have been nice if PEP-0318 was updated in advance of 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.

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Anthony Baxter]

On Thu, 5 Aug 2004 12:35:57 -0500, Edward K. Ream <ed*******@charter.net> wrote:

I could not disagree more. Pretending that discussions on py-dev and
SourceForge count as truly public discussions of pep 318 is most unwise.
pep 318 does not discuss '@' at all. People like me, with a strong interest
in how Python uses '@', would not naturally have known about the proposed
new syntax until the stuff hit the fan.
Sorry, but if discussions on python-dev are not considered "public", what is?
It's an open list, with publically available archives. Expecting the python-dev
team to read all of comp.lang.python is foolish - most of us have very little
spare time as it is. For instance, I usually only follow the list immediately
after a release. I have no time to wade through the hundreds of posts a day
on a regular basis. Indeed, I'm currently up way way too late at night to
participate in this discussion, because the chances are I'll have no time
tomorrow to do so.
Indeed, pep 318 is grossly misleading; reading it one gets the distinct
impression that the design is far from complete. It is my strong opinion
that _no_ public discussion of this new code has taken place, and none _can_
take place until we see what it is exactly that is being proposed.
See above. Exactly how is a public mailing list with an open subscription
policy, no limitations on who can post, and with web searchable archives,
not public. And if you think there hasn't been discussion on this matter,
you obviously haven't even bothered to look at the archives. There has
been a overwhelming amount of discussion on this.
This is
an issue of basic fairness and openness. I have complained loudly to the
[b]DFL. We shall see...

Fariness and openness? This isn't a debating club! As far as fairness - well,
after all the discussions were had, Guido made a judgment call. That's what
he does. Python, thank the gods, is not designed by some system of voting
and the like.

To summarise:
As I've stated already, I'm aware that PEP 318 needs an update. If no-one
else gets it done before next week, I will have time to work on it again. If one
of the people complaining about it wants to sit down and trawl the (literally)
hundreds and hundreds of python-dev messages, spread over the last 2+
years, and extract the relevant posts, that would be excellent! If you're only
going to sit and bitch about it, well, I can spend my time better trawling the
archives.

PEP 318 _will_ be updated and complete before 2.4 final is done - it's on my
list as a blocker for the final. Ideally (and I plan for this) it will
be done before a3.

Anthony

[Christopher T King]

On Fri, 6 Aug 2004, Anthony Baxter wrote:

To summarise: As I've stated already, I'm aware that PEP 318 needs an
update. If no-one else gets it done before next week, I will have time
to work on it again. If one of the people complaining about it wants to
sit down and trawl the (literally) hundreds and hundreds of python-dev
messages, spread over the last 2+ years, and extract the relevant posts,
that would be excellent! If you're only going to sit and bitch about it,
well, I can spend my time better trawling the archives.

I'd be willing to do this this weekend (esp. being Python Bug Day),
assuming Skip doesn't get to it first.

On a related note, I suggest anyone interested read this thread on
python-dev, "Call for defense of @decorators":
http://mail.python.org/pipermail/pyt...st/046878.html

In it, Guido makes some very interesting remarks, most notably:

I also want to find out about superior syntax proposals (from __future__
import decorators might be acceptable).

and

... I suggest that the proponents of syntax alternatives will have
to agree amongst themselves on a single alternative that they can
present to me.

[Peter Hansen]

Anthony Baxter wrote:

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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]

Anthony Baxter wrote:

On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax does.

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

[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
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Michael Hudson]

"Edward K. Ream" <ed*******@charter.net> writes:

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

--
112. Computer Science is embarrassed by the computer.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[Michael Hudson]

Peter Hansen <pe***@engcorp.com> writes:

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

Say what?

Cheers,
mwh

--
8. A programming language is low level when its programs require
attention to the irrelevant.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

[Ville Vainio]

>>>>> "Anthony" == Anthony Baxter <an***********@gmail.com> writes:

Anthony> On Thu, 05 Aug 2004 13:29:29 -0400, Peter Hansen <pe***@engcorp.com> wrote:

I'll make another donation to PSF if the final decorator syntax
does not Perlishly use arbitrary punctuation as the @ syntax
does.

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

--
Ville Vainio http://tinyurl.com/2prnb

[Terry Reedy]

"Christopher T King" <sq******@WPI.EDU> wrote in message
news:Pi**************************************@ccc6 .wpi.edu...

On Fri, 6 Aug 2004, Anthony Baxter wrote:

http://mail.python.org/pipermail/pyt...ead.html#45516
was over a month earlier.
That thread reaches no consensus,

To me this is evasion.
Steven Bethard wrote:

Wow, this one really feels like it was slipped in while no one was

looking.

You wrote: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]

On Thu, 5 Aug 2004, Terry Reedy wrote:

"Christopher T King" <sq******@WPI.EDU> wrote in message
news:Pi**************************************@ccc6 .wpi.edu...

That thread reaches no consensus,

To me this is evasion.

Well, it is.

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.

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

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.

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/pyt...ead.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.

Yes, it would have been nice if PEP-0318 was updated in advance of

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]

"Anthony Baxter" <an***********@gmail.com> wrote in message
news:e6************************@mail.gmail.com...

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]

Peter Hansen <pe***@engcorp.com> writes:

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]

On Wed, 4 Aug 2004 15:42:19 -0500, "Edward K. Ream" <ed*******@charter.net> wrote:

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]

st************@gmail.com (Steven Bethard) wrote in message news:<d1**************************@posting.google. com>...

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]

On 05 Aug 2004 22:16:44 +0300, Ville Vainio <vi***@spammers.com> wrote:

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]

On Thu, 5 Aug 2004 13:36:23 -0500, Edward K. Ream <ed*******@charter.net> wrote:

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]

In article <ma**************************************@python.o rg>,
Anthony Baxter <an***********@gmail.com> wrote:

On Thu, 5 Aug 2004 13:36:23 -0500, Edward K. Ream <ed*******@charter.net> wrote:

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.

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 (aa**@pythoncraft.com) <*> 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." --*****@lion.austin.ibm.com

[Erik Max Francis]

Skip Montanaro wrote:

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

--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Drifting from woman-who-tries misconstrued / Shifting to
woman-wise -- Lamya

[Anthony Baxter]

On 5 Aug 2004 23:43:29 -0400, Aahz <aa**@pythoncraft.com> wrote:

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.

[Peter Hansen]

Steven Bethard wrote:

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

The list-after-def is in that one sense as arbitrary as @, but at least
it feels more like Python. It would be clear that the decorators
are applied in the order presented in the list, and since the list
clearly isn't be a normal list (coming before the def), anyone reading
it would know that it must have something to do with the function
definition. (Anyway, as has been pointed out, the Java-based @ syntax
is not entirely arbitrary at this point, deriving from the Javadoc
comment syntax... I just think doc-generation system syntax embedded
inside code comments in another language is a poor place from which to
derive syntax for *Python*, which is why I said Python isn't exactly
leading in this area, but following, which is sad.)

The only negative mentioned for list-after-def that I've seen is that
with long argument lists it can be obscured. I wasn't aware of the very
wide range of possible uses for decorators (not that I think many of
them are really that important), but it does seem likely that with much
more than staticmethod/classmethod around, something like @ will end
up being required because decorators will add so much to the language
that someone will be incapable of using Python without knowing all about
decorators. (Viz. e.g. the "singleton" example, or "onexit")

If decorators will be used as much as it appears they will be, then the
"pie" syntax with the @ sign is perhaps best, simply because it is
so "in your face". Barry named it well...

(I would like to see an alternative with "from __future__ import "
as well, but I'm not the one doing the work on this...)

-Peter

[John Roth]

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:41***************@alcyone.com...

Skip Montanaro wrote:

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

Chuckle!

For those who haven't looked it up, it's a "sad face"
smiley (a frowney?)

John Roth
--
__ Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
\__/ Drifting from woman-who-tries misconstrued / Shifting to
woman-wise -- Lamya

[Michael Hudson]

"John Roth" <ne********@jhrothjr.com> writes:

"Erik Max Francis" <ma*@alcyone.com> wrote in message
news:41***************@alcyone.com...

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

Chuckle!

For those who haven't looked it up, it's a "sad face"
smiley (a frowney?)

unicodedata.name(u'\u2639')

'WHITE FROWNING FACE'

I like the unicodedata module :-)

Cheers,
mwh

--
The ability to quote is a serviceable substitute for wit.
-- W. Somerset Maugham

[Edward K. Ream]

> 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 have never said any such thing, nor did I mean to insinuate any such
thing. I have stated, loudly and often, that no proper public notice of
recent changes has been made. I stand by that statement.
"Actively mislead the public"? What the hell is that supposed to mean?

The fact is that somebody like me, with a big interest in '@', would
naturally conclude, on the basis on reading pep 318, that pep 318 has
nothing to do with '@'. Moreover, one would conclude, on the basis on
reading pep 318, that the pep wasn't even close to a final design, much less
an implementation.

That is what I meant, and _all_ that I meant, by the phrase "actively
misleading".

Edward
--------------------------------------------------------------------
Edward K. Ream email: ed*******@charter.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Bengt Richter]

On Thu, 5 Aug 2004 21:16:00 -0500, Skip Montanaro <sk**@pobox.com> wrote:

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

?

Yes, but then plain ascii editors would have an obscurity problem.
If you really want this context-sensitive function-stacking operator
whose stack is popped and applied to the result of the next def until
the stack is empty (is this effectively the rule?), why not just
leave it ascii encoded ;-)

:)decorator
def f():
pass

Hm, perhaps '@' could be the beginning of a hidden Forth syntax for python? ;-)

BTW, can anything (blank lines, comments, assignment statements) come between the
@decorator line and the function def? Can the decorator line be conditional? E.g.,
if __debug__: @add_my_debug_printouts
def foo(x,y): return x+y

BTW2, is @something a purely a prefixed extension of def syntax, or is it
a dynamic, code-generating operator that really does stack functions to
be used when the very next function-definition code (not the callable function code)
executes? If so, is @(expression) acceptable? I.e., could you write (untested ;-)
@(lambda f: (lambda *args,**kwargs: long(f(*args,**kwargs))))
instead of
@force_long_result
? I don't guess so ;-)

Could you use a module attribute expression?

@mydecorators.force_long_result

Why not? (I don't have a copy of 2.4 to play with (nor the time :-( )

But then, why an internal single anonymous stack to pop decorator functions from?
Why not use a named function source, that a programmer can control? That has an API
or protocol(usage?), so a programmer-defined object can override the functionality?

But if you have a named stack object, it could as well have ordinary methods for stack
access, and we wouldn't need a special stack-function-for-a-narrowly-defined-purpose
operator spelled '@' ;-) (BTW, does '@' stack functions or function names, actually?
I.e., does some_name have to be bound prior to the '@some_name' line? If names are
stacked, is a dotted name permissible? Probably not, right ;-)

You could define a stack object that would push args of __call__ so your syntax could be
decorate = __builtins__.metafunctions.push # say you prefer 'decorate' as name
...
decorate(accepts_ints, returns_longs)
def foo(x,y): return long(x+y)
or
decorate(accepts_ints)
decorate(returns_longs)
def foo(x,y): return long(x+y)

You'd just have to arrange for def to use metafunctions.pop (hence overridable, if
you want to shadow the standard metafunctions object in builtins) to get decorator
functions. Of course a user-friendly alias for metafunctions.push could also exist
in builtins. That's just a matter of choosing a name ("at_sign" ;-)

(See other post for other angles on using a builtin object (and associated class)
-- though the idea mix is evolving, and there are no warranties express or implied
against contradiction or for version compatibility among them ;-)

I know I have thrown out too many ideas to make a forceful pitch for any one of them.
I just want to illustrate that there may yet be unthought-of alternatives to '@' that
are more object-oriented and general, with potentially not that different a syntax
in actual use, I.e.,
AT(decorator) # assuming you like 'AT' as an alias
vs
@decorator

My USD.02

Regards,
Bengt Richter

[Shalabh Chaturvedi]

Peter Hansen wrote:

I'm also surprised that the choice which had the greatest public
support during the straw poll at PyCon isn't still under discussion,

I doubt any of the following would have made it in Python had it
followed the course of 'greatest public support':

1. Whitespace based blocks
2. Docstrings

Looking back, I remember when I started out with Python I had a "Eeww,
what's this!?" reaction to both of the above, very similar to what I
initially felt for @-decorator. After using it in my code I find it's
actually not bad at all. I'd prefer to use the '|' character for
aesthetics but am happy with @ as well.

Cheers,
Shalabh