decorators - more than just syntactic sugar

[Helmut Jarausch]

Hi,

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

Many thanks for your help,

Helmut Jarausch

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

[Marc 'BlackJack' Rintsch]

On Sat, 11 Aug 2007 20:30:54 +0200, Helmut Jarausch wrote:

are decorators more than just syntactic sugar in python 2.x and what
about python 3k ?

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

[Michele Simionato]

On Aug 11, 8:30 pm, Helmut Jarausch <[e-mail]:

Hi,

are decorators more than just syntactic sugar in python 2.x and what
about python 3k ?

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/li...l-cpdecor.html

Michele Simionato

[Kay Schluehr]

On Aug 11, 8:30 pm, Helmut Jarausch <[e-mail]:

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
sufficient, depending on your intention?

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

On 8/11/07, Helmut Jarausch <ja******@skynet.bewrote:

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.
--
mvh Björn

[Duncan Booth]

"BJörn Lindqvist" <bj*****@gmail.comwrote:

On 8/11/07, Helmut Jarausch <ja******@skynet.bewrote:

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

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

functools.wraps
contextlib.contextmanager

[Duncan Booth]

Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:

On Sat, 11 Aug 2007 20:30:54 +0200, Helmut Jarausch wrote:

>are decorators more than just syntactic sugar in python 2.x and what
about python 3k ?

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 <Xn*************************@127.0.0.1>
depends on this difference and will not work if you write the calls out
explicitly instead of using decorators.

[Sion Arrowsmith]

=?ISO-8859-1?Q?BJ=F6rn_Lindqvist?= <bj*****@gmail.comwrote:

>On 8/11/07, Helmut Jarausch <ja******@skynet.bewrote:

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

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.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Alexander Schmolck]

Michele Simionato <mi***************@gmail.comwrites:

On Aug 11, 8:30 pm, Helmut Jarausch <[e-mail]:

>Hi,

are decorators more than just syntactic sugar in python 2.x and what
about python 3k ?

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

[Bjoern Schliessmann]

BJörn Lindqvist wrote:

unpedagogically not separated from ordinary functions.

Decorators _are_ ordinary functions. Remember the "syntactic sugar"
in this thread?

Regards,
Björn

--
BOFH excuse #338:

old inkjet cartridges emanate barium-based fumes

[Michele Simionato]

On Aug 13, 7:46 pm, Alexander Schmolck <[e-mail]:

Michele Simionato <[e-mail]:

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

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

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

On 8/13/07, Bjoern Schliessmann
<us**************************@spamgourmet.comwrote :

BJörn Lindqvist wrote:

unpedagogically not separated from ordinary functions.

Decorators _are_ ordinary functions. Remember the "syntactic sugar"
in this thread?

Remember also "that syntactic sugar is important." Case in point, the
OP did not think of looking at the built-in functions page.

--
mvh Björn