473,703 Members | 2,331 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Maybe, just maybe @decorator syntax is ok after all

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
quicly. The situation might have been different if we had seen a
pronouncement a week before, in the vein of "I have chosen this syntax
- it will go in to the next alpha".

My chief worry was throwing away one of the few unused ascii symbols,
but if we take a look at perl6, there is a lot of promising unicode
symbols to choose from in the future ;-). Also, there is still @(),
@#, @{} and others in the hypothetical event BDFL would like to use @
for future features like macros, ruby blocks or whatever.

So I would vote +0 for @decorator if we were in the parallel universe
where that mattered. Two days ago I was -10.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #1
11 1626
Ville Vainio <vi***@spammers .com> wrote in message news:<du******* ******@mozart.c c.tut.fi>...
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.
You know what, I'm starting to feel the same. Yesterday Anthony Baxter
mentioned this URL:

http://mail.python.org/pipermail/pyt...st/047112.html

where GvR says:

"""
Given that the whole point of adding decorator syntax is to move the
decorator from the end ("foo = staticmethod(fo o)" after a 100-line
body) to the front, where it is more in-your-face, it should IMO be
moved all the way to the front.
"""

And I had the sudden feeling that I finally got it. You see, for me,
the @decorator syntax is a declaration - first thing that came to my
mind was Pascal's "forward". So it says "take the def that follows and
insert a (old style) decoration line in the code after it." Note that
here the "def" is recursive - it may have other @decorators before it.

I'm not sure I'm making myself clear; my understanding of it is more
by feeling than by logic. So let's say that @decorator is like a
preprocessor directive. If we have:

@dec1
@dec2
def foo():
pass

then after the first pass it becomes:

@dec2
def foo():
pass

foo = dec1(foo)

and after the second:

def foo():
pass

foo = dec2(foo)

foo = dec1(foo)

BTW, this interpretation leaves some space for future manipulation of
if/for/while/try statements.

Speaking of loop statements, they have an optional else clause that
isn't obvious either. It means "do this if there was no break-exit
from the loop." Yet for me the obvious meaning would be "if there were
no loop passes" - that is, the while condition was false on the first
entry or the for list was empty. I think the word "finally" would be
more to the point here (and it's a keyword anyway).

I think having some obscurity in the language is inevitable. The
present way of applying decorators (x = decor(x)) is equally cryptic
to a newbie as the @decor syntax will be - first you have to know what
a decorator is. There even aren't any decorators used in the standard
lib - or at least grep doesn't show any static/classmethod rebindings.
My chief worry was throwing away one of the few unused ascii symbols,
but if we take a look at perl6, there is a lot of promising unicode
symbols to choose from in the future ;-). Also, there is still @(),
@#, @{} and others in the hypothetical event BDFL would like to use @
for future features like macros, ruby blocks or whatever.
And we still have ? and $, plus the backtick (`) that now is for repr,
but in Python 3000 will hopefully be for "os.popen.read( ); ...close()"
like in bash for example, or something equally useful.
So I would vote +0 for @decorator if we were in the parallel universe
where that mattered. Two days ago I was -10.


Same here. I'm opposed to dictatorship in general - I grew up behind
the Iron Curtain - but the BDFL's decisions so far were mostly
beneficial, so I'll live with whatever he decides (I'm not saying this
as seriously as it sounds).

AdSR
Jul 18 '05 #2
AdSR wrote:
You know what, I'm starting to feel the same. Yesterday Anthony
Baxter mentioned this URL:

http://mail.python.org/pipermail/pyt...st/047112.html

where GvR says:

""" Given that the whole point of adding decorator syntax is to move
the decorator from the end ("foo = staticmethod(fo o)" after a
100-line body) to the front, where it is more in-your-face, it should
IMO be moved all the way to the front. """
I saw this quote, too, but it did not sway me. I've felt ever since the
C89 days that having too much stuff before the name being defined is an
impediment to understanding the code:

So, let's see here. We have a class method. It's memoized, it's
transacted, and it's ACID. Okay, so far, so good. It's takes two ints,
and returns an Exception. Okay. It was created on July 17, 2005, at
3:13:32 in the morning EST, by a guy named Guido. Good to know.

And it's named 'foo'. Which sucks, because I was looking for 'bar'.

Where was I again?

Having all this stuff before the *name* of the thing being defined is
distracting. First tell me what it's *called*, then I'll decide if I
want to know more or not.

Ever look at Java code? Abominations like "public static final
synchronized f() {}" litter the code. *shudder* How is one supposed to
navigate code like this?
And I had the sudden feeling that I finally got it. You see, for me,
the @decorator syntax is a declaration - first thing that came to my
mind was Pascal's "forward". So it says "take the def that follows
and insert a (old style) decoration line in the code after it." Note
that here the "def" is recursive - it may have other @decorators
before it.
That is the intent as I understand it. It even sounds reasonable, at
first blush. But Python is not supposed to need forward declarations.
And the other way of looking at it (an implicit stack of decorators held
by the parser, to be applied to the "next X" found) is equally strange.

Also, psychology tells us that people like to pick a starting location,
and move in one direction from there. We're all familiar with this: this
is how books are laid out. Having to scan *both* directions to see all
the pertinent information is like having the chapter title in the middle
of the chapter.

I'll kick this horse once more: if we were take this prefix idea to it's
logical conclusion, we'd put the function body before the function name!

global x
x *= a
def f( a)

This ain't Python to me.

People don't do well with prefix or postfix; we want infix or
sequential. That is why so many people still use "algebraic" calculators
even when RPN is often faster and requires less button presses.
Everything else in Python is either infix or sequential, why start
prefixing stuff now?
Speaking of loop statements, they have an optional else clause that
isn't obvious either. It means "do this if there was no break-exit
from the loop." Yet for me the obvious meaning would be "if there
were no loop passes" - that is, the while condition was false on the
first entry or the for list was empty. I think the word "finally"
would be more to the point here (and it's a keyword anyway).
Except that finally blocks *always* get executed; while else blocks get
executed only if the loop completes normally. I agree that it is an odd
word choice, but I assume they were simply trying to reuse a keyword.
I think having some obscurity in the language is inevitable. The
present way of applying decorators (x = decor(x)) is equally cryptic
to a newbie as the @decor syntax will be - first you have to know
what a decorator is. There even aren't any decorators used in the
standard lib - or at least grep doesn't show any static/classmethod
rebindings.


Right. The only benefit of decorators is that they get the decoration
closer to the start of the decorated. Locality matters when trying to
understand code.

-- Mark
Jul 18 '05 #3
Mark Bottjer wrote:
AdSR wrote:
You know what, I'm starting to feel the same. Yesterday Anthony
Baxter mentioned this URL:

http://mail.python.org/pipermail/pyt...st/047112.html

where GvR says:

""" Given that the whole point of adding decorator syntax is to move
the decorator from the end ("foo = staticmethod(fo o)" after a
100-line body) to the front, where it is more in-your-face, it should
IMO be moved all the way to the front. """


Now combine this with this message, which I just found:

http://mail.python.org/pipermail/pyt...st/047279.html

where GvR says:

"""In the discussion on decorators months ago, solutions involving
special syntax inside the block were ruled out early on. Basically,
you shouldn't have to peek inside the block to find out important
external properties of the function. (Yes, I know that docstrings
violate this principle. For the record, it would be better if they
were prefix too; and a prefix decorator syntax will let us fix this in
the future but introducing a "doc" decorator.)"""

So the position of the decorators is not open to debate. :(

-- Mark
Jul 18 '05 #4
ar**********@ya hoo.com (AdSR) wrote in message news:<b8******* *************** ****@posting.go ogle.com>...
<snip>
@dec1
@dec2
def foo():
pass

<snip>

and after the second:

def foo():
pass

foo = dec2(foo)

foo = dec1(foo)


The latter is equivalent to:

def foo():
pass
foo = dec1(dec2(foo))

But I've just noticed that the spec says:

"""
@f1
@f2
def func(): pass

is equivalent to:

def func(): pass
func = f2(f1(func))
"""

So the order is reverse, which breaks my previous interpretation. Oh, well...

AdSR
Jul 18 '05 #5
On Sunday 08 August 2004 18:28, Mark Bottjer wrote:
Having all this stuff before the *name* of the thing being defined is
distracting. First tell me what it's *called*, then I'll decide if I
want to know more or not.


Much of that can be accomplished stylistically in the way comments are
written (granted, that doesn't accomplish much for existing code that
doesn't follow such conventions). But, for example, in my C/C++ code, I
always have comments before my functions like so:

/*
* FooClass::foo()
*
* Fooifies the FooClass instance
*/
int FooClass::foo(i nt parm1, char parm2, char *spam_name)
....

Much of the problem (in any language, then) goes away. You still run
into problems with existing code, though.

-Michael
Jul 18 '05 #6
Michael Ekstrand <py****@elehack .net> wrote:
Much of that can be accomplished stylistically in the way comments are
written (granted, that doesn't accomplish much for existing code that
doesn't follow such conventions). But, for example, in my C/C++ code, I
always have comments before my functions like so:

/*
* FooClass::foo()
*
* Fooifies the FooClass instance
*/
int FooClass::foo(i nt parm1, char parm2, char *spam_name)


The problem there is that you need to repeat the name of the function.
This was one of the very reasons given for wanting to get away from

def foo ():
pass

foo = classmethod (foo)

in the first place. Not the only reason, by far, but certainly one of
them.
Jul 18 '05 #7
Michael Ekstrand wrote:
Much of that can be accomplished stylistically in the way comments are
written (granted, that doesn't accomplish much for existing code that
doesn't follow such conventions). But, for example, in my C/C++ code, I
always have comments before my functions like so:

/*
* FooClass::foo()
*
* Fooifies the FooClass instance
*/
int FooClass::foo(i nt parm1, char parm2, char *spam_name)
...

Much of the problem (in any language, then) goes away. You still run
into problems with existing code, though.


But it brings other problems. There's a principle called DRY,
for Don't Repeat Yourself, which comes from observations that
*any* repetition will lead to maintenance problems and other
difficulties, especially when refactoring code. And I can't
count the number of times I've seen comments such as the above
which were wrong, either through name changes or because of
the inevitable cut-and-paste errors.

At my last place of employment, we abolished all redundant
comments, such as those containing the name of the function or
module. The code got much shorter and cleaner.

-Peter
Jul 18 '05 #8
On 9 Aug 2004 07:07:54 -0700, ar**********@ya hoo.com (AdSR) wrote:
ar**********@y ahoo.com (AdSR) wrote in message news:<b8******* *************** ****@posting.go ogle.com>...
<snip>
@dec1
@dec2
def foo():
pass

<snip>

and after the second:

def foo():
pass

foo = dec2(foo)

foo = dec1(foo)


The latter is equivalent to:

def foo():
pass
foo = dec1(dec2(foo))

But I've just noticed that the spec says:

"""
@f1
@f2
def func(): pass

is equivalent to:

def func(): pass
func = f2(f1(func))
"""

So the order is reverse, which breaks my previous interpretation. Oh, well...

I think your example is not from the PEP. What "spec" are you citing?
Note the order in the example cut and pasted from the current
(Last-Modified: 2004/08/06 18:34:15) pep 318:
----
The current syntax for function decorators as implemented in Python 2.4a2 is:

@dec2
@dec1
def func(arg1, arg2, ...):
pass

This is equivalent to:

def func(arg1, arg2, ...):
pass
func = dec2(dec1(func) )
----

Regards,
Bengt Richter
Jul 18 '05 #9
bo**@oz.net (Bengt Richter) wrote in message news:<cf******* *************** ***@theriver.co m>...
On 9 Aug 2004 07:07:54 -0700, ar**********@ya hoo.com (AdSR) wrote:
<snip>
So the order is reverse, which breaks my previous interpretation. Oh, well...

I think your example is not from the PEP. What "spec" are you citing?


http://www.python.org/dev/doc/devel/ref/function.html
Jul 18 '05 #10

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

Similar topics

14
2309
by: Sandy Norton | last post by:
If we are going to be stuck with @decorators for 2.4, then how about using blocks and indentation to elminate repetition and increase readability: Example 1 --------- class Klass: def __init__(self, name):
23
1929
by: C. Barnes | last post by:
I vote for def f(): (body of function) This is backwards compatible (Python <= 2.3 raise SyntaxError), and looks much nicer than @. The only problem is that you can't one-line a decorated function. You can't do that with
24
2058
by: Steven Bethard | last post by:
I think one of the biggest reasons we're having such problems coming to any agreement on decorator syntax is that each proposal makes a number of syntax decisions, not just one. For decorators, I see the following decisions that must be made: 1) Indicator Proposals differ on how some sort of indicator of "decoratorhood" is use. These include: * none (e.g. just the list, as in the "list-after-def" suggestion) * the '@' character
37
2596
by: Bengt Richter | last post by:
ISTM that @limited_expression_producing_function @another def func(): pass is syntactic sugar for creating a hidden list of functions. (Using '|' in place of '@' doesn't change the picture much (except for people whose tools depend on '@' ;-)). I.e., (not having the source or time to delve) the apparent semantics of the above is something roughly like
7
1586
by: Steven Bethard | last post by:
So here's the state of the decorator debate as I see it: *** Location GvR pretty strongly wants decorators before the function: http://mail.python.org/pipermail/python-dev/2004-August/047112.html http://mail.python.org/pipermail/python-dev/2004-August/047279.html
41
2859
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):
12
1533
by: Steven Bethard | last post by:
The poll, as stated, asked voters to vote for the syntax suggestion they liked the /most/. Some of the conclusions people are trying to draw from it are what syntaxes people liked the /least/. This is probably not the right conclusion to be drawing from the poll that was given. It is, however, the kind of conclusion I think we'd like to draw. I'm not sure we're going to agree fully on a single "best" proposal, but it would help to...
28
2384
by: Paul McGuire | last post by:
Well, after 3 days of open polling, the number of additional votes have dropped off pretty dramatically. Here are the results so far: Total voters: 55 (with 3 votes each) Votes for each choice or group of choices: Any J 81 J2 78 Any C 40 C1 29 Any D 9
2
1361
by: Larry Hastings | last post by:
I didn't see this form of decorator syntax listed on the Python Decorator Wiki, but that page is now frozen so I'm posting it here. I realize the futility (and ignominy!) of posting such a thing, especially at such a late date, so I'm happy to say I have absolutely no ego invested in it ;) Behold: def foo(a, b), classmethod,
0
8759
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
8669
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
9251
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
9017
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
1
6588
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 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 a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
4433
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
4687
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
2
2453
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
2069
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

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.