decorators - more than just syntactic sugar

H

Helmut Jarausch

Hi,

are decorators more than just syntactic sugar in python 2.x and what
How can I find out the predefined decorators?

Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

M

Marc 'BlackJack' Rintsch

are decorators more than just syntactic sugar in python 2.x and what

They are just syntactic sugar.

@spam
def ham():
pass

is the same as

def ham():
pass

ham = spam(ham)
How can I find out the predefined decorators?

*The* predefined decorators? Decorators are just functions after all.
There are some meant to be used as decorators but there are also
"ordinary" functions that may make sense as decorators.

Ciao,
Marc 'BlackJack' Rintsch

M

Michele Simionato

Hi,

are decorators more than just syntactic sugar in python 2.x and what

Well, I argued may times that syntactic sugar is important (all Turing
complete languages differs by syntactic sugar only) and having or not
having
a given syntactic sugar makes a difference between writing and not
writing
a given program. Having decorators in core Python makes us think
differently.
Have a look at David Mertz article

http://www.ibm.com/developerworks/linux/library/l-cpdecor.html

Michele Simionato

K

Kay Schluehr

How can I find out the predefined decorators?

I dare to say that's not easy. Since decorators are just(?)
syntactical sugar they don't obtain a particular semantics expressed
by distinctive declarative elements. Unlike generators which can be
identified looking for a yield expression a decorator can be
identified syntactically just when it is used. However this might be

?

=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?=

How can I find out the predefined decorators?

There are two in the standard library, @classmethod for declaring
class methods and @staticmethod for declaring static methods. They are
listed at the built ins page
http://docs.python.org/dev/lib/built-in-funcs.html, unpedagogically
not separated from ordinary functions.

D

Duncan Booth

BJörn Lindqvist said:
There are two in the standard library, @classmethod for declaring
class methods and @staticmethod for declaring static methods. They are
listed at the built ins page
http://docs.python.org/dev/lib/built-in-funcs.html, unpedagogically
not separated from ordinary functions.

There are at least two other decorators in the standard library:

functools.wraps
contextlib.contextmanager

D

Duncan Booth

Marc 'BlackJack' Rintsch said:
They are just syntactic sugar.

@spam
def ham():
pass

is the same as

def ham():
pass

ham = spam(ham)

Decorators are almost just syntactic sugar, but in fact there is a subtle
difference between the two bits of code you gave: in the second one you
assign the function to the name ham and then replace it with the result of
calling spam. With the decorator syntax you only have one assignment to ham
and when that decorator is called that assignment has not yet happened.

The difference is small, but you can write decorators which depend on it.
For example, the code I posted in <[email protected]>
depends on this difference and will not work if you write the calls out

S

Sion Arrowsmith

=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= said:
There are two in the standard library, @classmethod for declaring
class methods and @staticmethod for declaring static methods. They are
listed at the built ins page
http://docs.python.org/dev/lib/built-in-funcs.html, unpedagogically
not separated from ordinary functions.

That page also demonstrates how property() can be used as a
decorator for conveniently creating read-only properties,
further emphasising the fact that a decorator really is an
ordinary function.

A

Alexander Schmolck

Michele Simionato said:
Well, I argued may times that syntactic sugar is important (all Turing
complete languages differs by syntactic sugar only)

Although I agree that "mere" syntactic sugar matters, I think you're
overstating the point. I would argue that most people would understand
syntactic sugar as equivalent to a (very) localized program transformation.
Things like first class continuations clearly aren't syntactic sugar in that
sense.

'as

B

Bjoern Schliessmann

BJörn Lindqvist said:
unpedagogically not separated from ordinary functions.

Decorators _are_ ordinary functions. Remember the "syntactic sugar"

Regards,

Björn

M

Michele Simionato

Although I agree that "mere" syntactic sugar matters, I think you're
overstating the point. I would argue that most people would understand
syntactic sugar as equivalent to a (very) localized program transformation.
Things like first class continuations clearly aren't syntactic sugar in that
sense.

'as

I don't think I am overstating my point. I am just pointing out
a sloppiness in the definition of "syntactic sugar". You are right
that most people understand it as °a somewhat trivial
program transformation". However most people tend to forget that
by a succession of somewhat trivial program transformations you
can get quite a lot. Look, a compiled language is just a whole big lot
of syntactic sugar over assembly language!
An even continuations can be implemented in terms of macros. the
quintessence of syntactic
sugar (as you know better than me). You are right that this
require a global program transformation, it is a kind of heavy
duty syntactic sugar, but still it is always syntactic sugar
at the end. Then, you may decide that you want to use a different
name from global program transformation, since syntactic sugar
sounds diminutive, but then it is an issue of names

Michele Simionato