473,320 Members | 1,691 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

decorator J4 - any objections?

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
Jul 18 '05 #1
17 1683
Ji********@yahoo.com (Jim Jewett) writes:
<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
Jul 18 '05 #2
Paul Rubin <http://ph****@nospam.invalid> wrote:

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
Jul 18 '05 #3
Martin DeMello <ma***********@yahoo.com> writes:
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.


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.
Jul 18 '05 #4
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.

"Jim Jewett" <Ji********@yahoo.com> wrote in message
news:ca**************************@posting.google.c om...
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

Jul 18 '05 #5
"Larry Bates" <lb****@swamisoft.com> writes:
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.
Jul 18 '05 #6
Larry Bates wrote:
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

Jul 18 '05 #7
On Fri, 20 Aug 2004 17:59:18 -0500, rumours say that "Larry Bates"
<lb****@swamisoft.com> might have written:
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.
--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
Jul 18 '05 #8
Christos "TZOTZIOY" Georgiou <tz**@sil-tec.gr> writes:
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?
Jul 18 '05 #9
Larry Bates wrote:
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 ?

Jul 18 '05 #10
In article <7x************@ruckus.brouhaha.com>,
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Christos "TZOTZIOY" Georgiou <tz**@sil-tec.gr> writes:

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?


Yes.
--
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
Jul 18 '05 #11
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
Jul 18 '05 #12
Jeffrey Froman <Je*****@Fro.man> writes:
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.


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.
Jul 18 '05 #13
Paul Rubin wrote:
Jeffrey Froman <Je*****@Fro.man> writes:
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.

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
Jul 18 '05 #14
Paul Rubin <http://ph****@nospam.invalid> wrote:
Martin DeMello <ma***********@yahoo.com> writes:
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.


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
Jul 18 '05 #15
Jeff Shannon <je**@ccvcorp.com> wrote:

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):
Jul 18 '05 #16
Martin DeMello wrote:
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
Jul 18 '05 #17
On 20 Aug 2004 17:20:13 -0700, rumours say that Paul Rubin
<http://ph****@NOSPAM.invalid> might have written:
Christos "TZOTZIOY" Georgiou <tz**@sil-tec.gr> writes:
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?


Try the following in 2.4a2:
from test.test_decorators import memoize
class A: @memoize
@staticmethod
def add1(a,b):
return a+b
@staticmethod
@memoize
def add2(a,b):
return a+b
A.add1(1,2)
A.add2(1,2)

--
TZOTZIOY, I speak England very best,
"Tssss!" --Brad Pitt as Achilles in unprecedented Ancient Greek
Jul 18 '05 #18

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
by: Ville Vainio | last post by:
It might just be that @decorator might not be all that bad. When you look at code that uses it it's not that ugly after all. A lot of the furor about this is probably because it happened so...
41
by: John Marshall | last post by:
How about the following, which I am almost positive has not been suggested: ----- class Klass: def __init__(self, name): self.name = name deco meth0: staticmethod def meth0(x):
30
by: Ron_Adam | last post by:
I was having some difficulty figuring out just what was going on with decorators. So after a considerable amount of experimenting I was able to take one apart in a way. It required me to take a...
22
by: Ron_Adam | last post by:
Hi, Thanks again for all the helping me understand the details of decorators. I put together a class to create decorators that could make them a lot easier to use. It still has a few glitches...
3
by: Ron_Adam | last post by:
Ok... it's works! :) So what do you think? Look at the last stacked example, it process the preprocess's first in forward order, then does the postprocess's in reverse order. Which might be...
6
by: Michele Simionato | last post by:
could ildg wrote: > I think decorator is a function which return a function, is this right? > e.g. The decorator below if from http://www.python.org/peps/pep-0318.html#id1. > > def...
5
by: Doug | last post by:
I am looking at using the decorator pattern to create a rudimentary stored proc generator but am unsure about something. For each class that identifies a part of the stored proc, what if I want to...
4
by: thomas.karolski | last post by:
Hi, I would like to create a Decorator metaclass, which automatically turns a class which inherits from the "Decorator" type into a decorator. A decorator in this case, is simply a class which...
8
by: Chris Forone | last post by:
hello group, is there a possibility to implement the decorator-pattern without new/delete (nor smartpt)? if not, how to ensure correct deletion of the objects? thanks & hand, chris
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.