Confused about pep 318

[Tor Iver Wilhelmsen]

Re: Confused about pep 318

Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> And Java chose it based on what precedent?[/color]

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:

@ImplementsRequ irement("B2")
public void adjustPrices(Ar rayList<Price> prices) {
//...
}

C# 2.0 (for the generics):

[ImplementsRequi rement("B2")]
public void AdjustPrices(Ar rayList<Price> prices) {
// ...
}

[Bengt Richter]

Re: Confused about pep 318

On Wed, 4 Aug 2004 15:42:19 -0500, "Edward K. Ream" <edreamleo@char ter.net> wrote:
[color=blue]
>Hello all,[/color]
[... 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]

Re: Confused about pep 318

steven.bethard@ gmail.com (Steven Bethard) wrote in message news:<d11dcfba. 0408050801.27b5 c69d@posting.go ogle.com>...[color=blue]
>
> 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...
>[/color]

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]

Re: Confused about pep 318

On 05 Aug 2004 22:16:44 +0300, Ville Vainio <ville@spammers .com> wrote:[color=blue]
> 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.[/color]

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]

Re: Confused about pep 318


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]

Re: Confused about pep 318

On Thu, 5 Aug 2004 13:36:23 -0500, Edward K. Ream <edreamleo@char ter.net> wrote:[color=blue]
> 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.[/color]

"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]

Re: Confused about pep 318


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\xbadec orator
def f():
pass

?

Skip

[Aahz]

Re: Confused about pep 318

In article <mailman.1241.1 091758030.5135. python-list@python.org >,
Anthony Baxter <anthonybaxter@ gmail.com> wrote:[color=blue]
>On Thu, 5 Aug 2004 13:36:23 -0500, Edward K. Ream <edreamleo@char ter.net> wrote:[color=green]
>>
>> 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.[/color]
>
>"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.[/color]

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.pytho n 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 (aahz@pythoncra ft.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." --reddy@lion.aust in.ibm.com

[Erik Max Francis]

Re: Confused about pep 318

Skip Montanaro wrote:
[color=blue]
> 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\xbadec orator
> def f():
> pass
>
> ?[/color]

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 && max@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]

Re: Confused about pep 318

On 5 Aug 2004 23:43:29 -0400, Aahz <aahz@pythoncra ft.com> wrote:[color=blue]
> Also, there has historically been an expectation that PEPs will be
> posted to comp.lang.pytho n in their final draft form;[/color]

That's news to me, although I think it's probably a good idea.
[color=blue]
> 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.[/color]

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]

Re: Confused about pep 318

Steven Bethard wrote:[color=blue]
> 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 @.[/color]

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]

Re: Confused about pep 318


"Erik Max Francis" <max@alcyone.co m> wrote in message
news:411304AB.F 53A5275@alcyone .com...[color=blue]
> Skip Montanaro wrote:
>[color=green]
> > 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\xbadec orator
> > def f():
> > pass
> >
> > ?[/color]
>
> Given how things are looking so far with the reaction to the decorator
> syntax, I'd say U+2639 might be more appropriate ...[/color]

Chuckle!

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

John Roth[color=blue]
>
> --
> __ Erik Max Francis && max@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[/color]

[Michael Hudson]

Re: Confused about pep 318

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> "Erik Max Francis" <max@alcyone.co m> wrote in message
> news:411304AB.F 53A5275@alcyone .com...
>[color=green]
> > Given how things are looking so far with the reaction to the decorator
> > syntax, I'd say U+2639 might be more appropriate ...[/color]
>
> Chuckle!
>
> For those who haven't looked it up, it's a "sad face"
> smiley (a frowney?)[/color]
[color=blue][color=green][color=darkred]
>>> unicodedata.nam e(u'\u2639')[/color][/color][/color]
'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]

Re: Confused about pep 318

> Look, you keep insinuating that there was some sort of evil plot to slip[color=blue]
> 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.[/color]

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.
[color=blue]
> "Actively mislead the public"? What the hell is that supposed to mean?[/color]

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: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[Bengt Richter]

Re: Confused about pep 318

On Thu, 5 Aug 2004 21:16:00 -0500, Skip Montanaro <skip@pobox.com > wrote:
[color=blue]
>
> 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\xbadec orator
> def f():
> pass
>
>?[/color]
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_p rintouts
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_res ult
? I don't guess so ;-)

Could you use a module attribute expression?

@mydecorators.f orce_long_resul t

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__.me tafunctions.pus h # say you prefer 'decorate' as name
...
decorate(accept s_ints, returns_longs)
def foo(x,y): return long(x+y)
or
decorate(accept s_ints)
decorate(return s_longs)
def foo(x,y): return long(x+y)

You'd just have to arrange for def to use metafunctions.p op (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.p ush 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