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 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
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
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.
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
"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.
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
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
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?
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 ?
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
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
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.
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
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
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):
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
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
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...
|
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):
|
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...
|
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...
|
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...
|
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...
|
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...
|
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...
|
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
|
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...
|
by: ryjfgjl |
last post by:
ExcelToDatabase: batch import excel into database automatically...
|
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...
|
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...
|
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...
|
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)...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
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...
|
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...
| |