Confused about pep 318

[Peter Hansen]

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]

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

 

[Michael Hudson]

Chuckle!

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

'WHITE FROWNING FACE'

I like the unicodedata module

Cheers,
mwh

 

[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

 

[Bengt Richter]

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]

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