decorator with keyword

[Peter Otten]

I'm sure they have been mentioned somewhere but here are some more
advantages of a decorator keyword (I use "transform"):

- The docstring can be moved to the top of the decorator suite.
- Simple attributes that don't affect the function's operation directly can
be written in the "natural" name = value form.
- Though I expect them to be rare like they are in classes today, statements
like if __debug__: decorateForDebugging would be possible.

A docstring and a single decorator - the common case:

transform:
""" Factory for new decorator syntaxes.

Keeps all proposals in a list and will recombine
them at random if called without a spec. """
staticmethod
def makeDecoratorSyntax(spec=None):
raise NotImplementedException()

The same with a pie:

@staticmethod
def makeDecoratorSyntax(spec=None):
""" Factory for new decorator syntaxes.

Keeps all proposals in a list and will recombine
them at random if called without a spec. """
raise NotImplementedException()

I'd say no clear winner here. Now a heavily decorated function:

transform:
"""This method blah, blah.

It supports the following arguments:
- longArgumentOne -- a string giving ...
- longArgumentTwo -- a number giving ...

blah, blah.

"""
author = "BDFL"
status = "experimental"
grammar = "'@' dotted_name [ '(' [arglist] ')' ]"
staticmethod
def longMethodNameForEffect(longArgumentOne=None,
longArgumentTwo=42):
if longArgumentOne is None:
longArgumentOne = setDefault(longArgumentTwo)
for line in longArgumentOne:
if not isBogus(line):
print line

The same with pies:

@funcattrs(author="BDFL", status="experimental",
grammar="'@' dotted_name [ '(' [arglist] ')' ]")
@staticmethod
def longMethodNameForEffect(longArgumentOne=None,
longArgumentTwo=42):
"""This method blah, blah.

It supports the following arguments:
- longArgumentOne -- a string giving ...
- longArgumentTwo -- a number giving ...

blah, blah.

"""
if longArgumentOne is None:
longArgumentOne = setDefault(longArgumentTwo)
for line in longArgumentOne:
if not isBogus(line):
print line

A long docstring can indeed tear apart signature and implementation.

For the sake of completeness, a plain old function:

def filter(cond, seq):
"""filter(function or None, sequence) -> list, tuple, or string

Return those items of sequence for which function(item) is true. If
function is None, return the items that are true. If sequence is a
tuple or string, return the same type, else return a list."""

if cond is None:
cond = bool
return [item for item in seq if cond(item)]

transform:
"""filter(function or None, sequence) -> list, tuple, or string

Return those items of sequence for which function(item) is true. If
function is None, return the items that are true. If sequence is a
tuple or string, return the same type, else return a list."""
def filter(cond, seq):
if cond is None:
cond = bool
return [item for item in seq if cond(item)]

"transform" looks a bit pathetic for a docstring, but otherwise I'd say the
grouping might even be slighly clearer. Note how the function signature is
duplicated in the docstring taken from 2.3's filter() - that helps a lot
for long decoration suites.

The decoration suite would generate a list of (name, value) tuples which are
applied to the function like so

trafos = [("__doc__", "This method..."), ("author", "BDFL"), ..., (None,
staticmethod)]
trafos.reverse()
for name, value in trafos:
if name:
setattr(func, name, value)
else:
func = value(func)

I think I would even prefer something like the above over the current
classdict passed to metaclasses, i. e. ordering information and "unnamed
attributes" could be useful in classes, too.

Peter

[Christopher T King]

On Thu, 12 Aug 2004, Peter Otten wrote:

[decorator examples]

+2 on this (can I give a +2?). It's not only pretty, but it addresses my
gripe about decorators being used for too many purposes (by providing a
clean way to supply function attributes). Additionally, by moving
docstrings into the transform: block, this provides an easy way to
document the generated function, rather than forcing decorators to
preserve docstrings by copying the decoratee's docstring into the
decorated function.

The PythonDecorators wiki doesn't say Guido has specifically shot this
style down, so it may yet have a chance.

[Peter Hansen]

Christopher T King wrote:

[about the "decorate:" syntax]

The PythonDecorators wiki doesn't say Guido has specifically shot this
style down, so it may yet have a chance.

The python-dev mailing list doesn't appear to have discussed this one
yet, but given that much of the, uh, "chatter" that I detect there
is about minor tweaking of the @pie syntax, I fear they are so not
likely to pay much attention to new syntaxes and it might be too
late to get much support for it amongst the core folks. (Guido
referred to @pie as "the humble @decorator" yesterday...)

-Peter

[Reinhold Birkenfeld]

Christopher T King wrote:

On Thu, 12 Aug 2004, Peter Otten wrote:

[decorator examples]

+2 on this (can I give a +2?). It's not only pretty, but it addresses my
gripe about decorators being used for too many purposes (by providing a
clean way to supply function attributes). Additionally, by moving
docstrings into the transform: block, this provides an easy way to
document the generated function, rather than forcing decorators to
preserve docstrings by copying the decoratee's docstring into the
decorated function.

The PythonDecorators wiki doesn't say Guido has specifically shot this
style down, so it may yet have a chance.

I would also support this variant. I was a supporter of list-after-def,
but this seems to me pythonic AND readable.

+1! Hope Guido hears about that proposal!

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Reinhold Birkenfeld]

Peter Hansen wrote:

Christopher T King wrote:

[about the "decorate:" syntax]

The PythonDecorators wiki doesn't say Guido has specifically shot this
style down, so it may yet have a chance.

The python-dev mailing list doesn't appear to have discussed this one
yet, but given that much of the, uh, "chatter" that I detect there
is about minor tweaking of the @pie syntax, I fear they are so not
likely to pay much attention to new syntaxes and it might be too
late to get much support for it amongst the core folks. (Guido
referred to @pie as "the humble @decorator" yesterday...)

I'm sure it would help if every supporter of this syntax started a
thread of his own on python-dev *wink*

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Peter Hansen]

Reinhold Birkenfeld wrote:

Peter Hansen wrote:

The python-dev mailing list doesn't appear to have discussed this one
yet, but given that much of the, uh, "chatter" that I detect there
is about minor tweaking of the @pie syntax, I fear they are so not
likely to pay much attention to new syntaxes and it might be too
late to get much support for it amongst the core folks. (Guido
referred to @pie as "the humble @decorator" yesterday...)

I'm sure it would help if every supporter of this syntax started a
thread of his own on python-dev *wink*

Glad you put the wink in... I doubt that would help the
cause.

The syntax should be presented there, perhaps, preferably
by someone calm and reasonable (i.e. not me), but I think
the most valuable thing is to continue discussion here
until it's apparent (if that's going to happen) that there
is a fairly wide consensus that decorate: (possibly with
a different keyword) is far preferred to @pie... At least,
I think that was roughly what was asked for of the masses,
if the masses had anything to say about the matter.

-Peter

[Reinhold Birkenfeld]

Peter Hansen wrote:

Reinhold Birkenfeld wrote:

Peter Hansen wrote:

The python-dev mailing list doesn't appear to have discussed this one
yet, but given that much of the, uh, "chatter" that I detect there
is about minor tweaking of the @pie syntax, I fear they are so not
likely to pay much attention to new syntaxes and it might be too
late to get much support for it amongst the core folks. (Guido
referred to @pie as "the humble @decorator" yesterday...)

I'm sure it would help if every supporter of this syntax started a
thread of his own on python-dev *wink*

Glad you put the wink in... I doubt that would help the
cause.

The syntax should be presented there, perhaps, preferably
by someone calm and reasonable (i.e. not me), but I think
the most valuable thing is to continue discussion here
until it's apparent (if that's going to happen) that there
is a fairly wide consensus that decorate: (possibly with
a different keyword) is far preferred to @pie... At least,
I think that was roughly what was asked for of the masses,
if the masses had anything to say about the matter.

Full ACK!

Reinhold

--
Wenn eine Linuxdistribution so wenig brauchbare Software wie Windows
mitbrächte, wäre das bedauerlich. Was bei Windows der Umfang eines
"kompletten Betriebssystems" ist, nennt man bei Linux eine Rescuedisk.
-- David Kastrup in de.comp.os.unix.linux.misc

[Anthony Baxter]

On Thu, 12 Aug 2004 23:03:39 -0400, Peter Hansen <pe***@engcorp.com> wrote:

Reinhold Birkenfeld wrote:

I'm sure it would help if every supporter of this syntax started a
thread of his own on python-dev *wink* Glad you put the wink in... I doubt that would help the
cause.

And Brett Cannon would probably have you whacked if you did it.

that there
is a fairly wide consensus that decorate: (possibly with
a different keyword) is far preferred to @pie...
FWIW, I still prefer pie-decorators to decorate. That's just
from translating my trusty decorator-testbed-code into it.
At least,
I think that was roughly what was asked for of the masses,
if the masses had anything to say about the matter.

Pretty much - although the theory was that there would need
to be a discussion on technical merits of one over the other,
rather than "here's a list of people who prefer this or that".
But you knew that already...