decorator J4 - any objections?

[Jim Jewett]

Guido has said that he is open to considering *one* alternative
decorator syntax. At the moment, (Phillip Eby's suggestion) J4

<URL: http://www.python.org/moin/PythonDecorators > (section 5.21 J4)

looks very good to me -- and it is the only alternative without negatives.

def func(arg1, arg2)
@version("Added in 2.4")
@returns(None)
as:
"""Docstring could be here, or in decorator part above"""
# body goes here

(Note the lack of colon on the func line; adding it would be more
consistent and not hurt readability.)

def func(arg1, arg2):
@version("Added in 2.4")
@returns(None)
as:
"""Docstring could be here, or in decorator part above"""
# body goes here

While I think this is the best solution so far, I realize that others
have often disagreed with me on this issue -- so I would appreciate
some feedback, particularly from those who don't like the J4 syntax.

Disclosure: I like decorators on their own, but they are enough of
a special case that I worry about cluttering up the language as a
whole. J4 seems the best compromise to me, but I could also make
peace with Guido's current @proposal.

-jJ

 

[Paul Rubin]

<URL: http://www.python.org/moin/PythonDecorators > (section 5.21 J4)

looks very good to me -- and it is the only alternative without negatives.

def func(arg1, arg2)
@version("Added in 2.4")
@returns(None)
as:
"""Docstring could be here, or in decorator part above"""
# body goes here

What was wrong with using . or - instead of @ ? Given that this is
new syntax, just about any character could work. Or what about no
special punctuation at all? Using @ makes me cringe somewhat.

Also, why the need for the "as" keyword? What happens if it's just
eliminated? I.e.:

def func(arg1, arg2)
@version("Added in 2.4")
@returns(None):

"""Docstring could be here, or in decorator part above"""
# body goes here

 

[Martin DeMello]

Also, why the need for the "as" keyword? What happens if it's just
eliminated? I.e.:

def func(arg1, arg2)
@version("Added in 2.4")
@returns(None):

"""Docstring could be here, or in decorator part above"""
# body goes here

It's really nice to have an outdented marker for when the actual
function body begins.

martin

 

[Paul Rubin]

It's really nice to have an outdented marker for when the actual
function body begins.

I don't really see why, but the decorators don't have to be indented:

def func(arg1, arg2)
-version("Added in 2.4")
-returns(None):

"""Docstring could be here, or in decorator part above"""
# body goes here

I guess that's ugly though.

 

[Larry Bates]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.

def func(arg1, arg2):
{'version': 'Added in 2.4',
'returns': None,
'docstring': 'Docstring could be here, or in decorator part above'}
"""Docstring could be here, or in decorator part above"""

or perhaps:


def func(arg1, arg2):
#
# Similiar to class __dict__
#
__decorators__=__{'version': 'Added in 2.4',
'returns': None,
'docstring': 'Docstring could be here, or in decorator
part above'}
"""Docstring could be here, or in decorator part above"""


I'm sure there is a reason, but it would seem to make
"Python"-sense to me. It would then be very extensible
for the meta-data that everyone seems to also want decorators
to support.

 

[Paul Rubin]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.

I like that. Please add it to the wiki.

 

[Jeff Shannon]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.
[...]

I'm sure there is a reason, but it would seem to make
"Python"-sense to me. It would then be very extensible
for the meta-data that everyone seems to also want decorators
to support.

The biggest reason that I'm aware of is that GvR has declared that he
doesn't think decorators belong inside a function def, and has even been
quoted as having professed a regret for having put docstrings there.
(Personally, I think that having all of this stuff immediately inside
the function def makes great sense, but I'm not a world-famous language
designer, so what do I know? )

In fact, the biggest problem that I can see with the J4 syntax is its
close similarity to all of the decorator-inside-def variations. Since
GvR has spoken strongly against putting decorators in that location, it
seems to me to be a waste of effort to advocate for that. Now, perhaps
having that outdented keyword to indicate the function-body start
*might* make a difference with him... but I would expect that it won't.

Jeff Shannon
Technician/Programmer
Credit International

 

[Christos TZOTZIOY Georgiou]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.

Why type decorators as a dictionary if you are not going to produce a
dictionary? Cause if you produce a dictionary, the order of the
decorators is no longer guaranteed.

 

[Paul Rubin]

Why type decorators as a dictionary if you are not going to produce a
dictionary? Cause if you produce a dictionary, the order of the
decorators is no longer guaranteed.

Does that matter?

 

[Christophe Cavalaria]

If docstring can be a special case of a triple quoted
string, I don't see why decorators couldn't be a special
case of a dictionary.

def func(arg1, arg2):
{'version': 'Added in 2.4',
'returns': None,
'docstring': 'Docstring could be here, or in decorator part above'}
"""Docstring could be here, or in decorator part above"""

or perhaps:


def func(arg1, arg2):
#
# Similiar to class __dict__
#
__decorators__=__{'version': 'Added in 2.4',
'returns': None,
'docstring': 'Docstring could be here, or in
decorator
part above'}
"""Docstring could be here, or in decorator part above"""


I'm sure there is a reason, but it would seem to make
"Python"-sense to me. It would then be very extensible
for the meta-data that everyone seems to also want decorators
to support.

Maybe because decorators aren't just function properties but functions that
transform the function they receive in parameter. Therefore, that proposal
doesn't solve the problem at hand. It's a bad solution.

How would you do the staticmethod ou the memoize with that proposal ?

 

[Aahz]

Does that matter?

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

 

[Jeffrey Froman]

Jim Jewett wrote:

def func(arg1, arg2)
@version("Added in 2.4")
@returns(None)
as:
"""Docstring could be here, or in decorator part above"""
# body goes here

I like this better than the current proposal because it reads from top to
bottom, and flows like a typical conditional.

Before function writing the decorators whereas like reads this.

Jeffrey

 

[Paul Rubin]

I like this better than the current proposal because it reads from top to
bottom, and flows like a typical conditional.

Before function writing the decorators whereas like reads this.

J4 is my favorite of the enumerated proposals I remember, so I'll
"vote" for it, but I still think something better should be possible.

 

[Paul Morrow]

J4 is my favorite of the enumerated proposals I remember, so I'll
"vote" for it, but I still think something better should be possible.

It seems to me that we've had decorators all along (if we expand the
definition a little), for example __metaclass__ sure looks like a class
decorator. So how about...

def func(arg1, arg2):
"""Docstring goes here, as normal."""
__version__ = 'Added in 2.4'
__returns__ = None
# function body goes here

def returns(func, *args):
"""Docstring for 'returns' decorator."""
__decorator__ = True
# body of decorator goes here

 

[Martin DeMello]

I don't really see why, but the decorators don't have to be indented:

def func(arg1, arg2)
-version("Added in 2.4")
-returns(None):

"""Docstring could be here, or in decorator part above"""
# body goes here

I guess that's ugly though.

Yep. What I love about J4 is it lets you scan a file very quickly,
jumping from function to function and to the body when you find the one
you want. Very little visual clutter.

martin

 

[Martin DeMello]

In fact, the biggest problem that I can see with the J4 syntax is its
close similarity to all of the decorator-inside-def variations. Since
GvR has spoken strongly against putting decorators in that location, it
seems to me to be a waste of effort to advocate for that. Now, perhaps
having that outdented keyword to indicate the function-body start
*might* make a difference with him... but I would expect that it won't.

The advantage J4 has over J2 is that "def function <decorators> as
<body>" reads much better than "decorate <decorators> def function
<body>" - expected from English syntax is 'decorate def function <body>
with <decorators>'.

Perhaps J2 but with proposal L to call the decorator declaration
something other than "decorate" - 'using' is the best I've seen so far,
though it's still not perfect. Or another idea - how about inverting the
meaning of 'as', and changing the form of the decorator declarations
slightly?

as:
classmethod
memoised
accepting (int, int)
returning (float)
def foo(bar, baz):
.
.
.

martin



martin

 

[Nicolas Fleury]

Perhaps J2 but with proposal L to call the decorator declaration
something other than "decorate" - 'using' is the best I've seen so far,
though it's still not perfect. Or another idea - how about inverting the
meaning of 'as', and changing the form of the decorator declarations
slightly?

as:
classmethod
memoised
accepting (int, int)
returning (float)
def foo(bar, baz):

But Guido already said he wanted to keep as for other meanings.

Regards,
Nicolas

 

[Christos TZOTZIOY Georgiou]

Does that matter?

Try the following in 2.4a2:
@memoize
@staticmethod
def add1(a,b):
return a+b
@staticmethod
@memoize
def add2(a,b):
return a+b