Mailman 3 Decorator syntax restriction - Python-ideas

newer
Options parsing in the Tornado Web...

Decorator syntax restriction

Rob Cliffe

6 Sep 2009 6 Sep '09

9:41 a.m.

Can I make another plea for the syntax following '@' to be an unrestricted expression? Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it. 1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language. 2) The restriction is in any case more apparent than real, as @ <any-expression> # disallowed, SyntaxError can be implemented, albeit in a more verbose aka less Pythonic was, as: AnyExpr = <any-expression> @AnyExpr or as def Identity(x): return x ... @Identity( <any-expression> ) # smuggle in as func arg 3) I propose the following as plausible use cases (I know other people will have their own): 3.1) @DecoratorList[index] 3.2) @DecoratorDictionary[key] 3.3) @Decorator1 if <condition> else Decorator2 # Special case of the last one: def Identity(x): return x @Decorator if __debug__ else Identity Xavier Morel has pointed out that 3.1) can be implemented now as @DecoratorList.__getitem__[index] but this doesn't seem a good reason for forbidding the simpler syntax; after all Python allows the simpler syntax in other contexts. Similarly 3.2) can be written as @DecoratorDictionary.get(key) (As an aside, perhaps a decorator that evaluates to None could be treated at run-time the same as no decorator, i.e. equivalent to the Identity function in the above examples. Currently it naturally raises TypeError: 'NoneType' object is not callable. Just a thought.) Finally, sorry if I have not sent this e-mail to the right place (I wanted to attach it to the 'allow lambdas as decorators' thread but don't yet know how to do this). Also sorry that this partly duplicates a message I sent to python-dev. I am still finding my way round the Python mailing lists. Best wishes Rob Cliffe

Attachments:

attachment.htm (text/html — 4.3 KB)

Show replies by date

Daniel Fetchinson

6 Sep 6 Sep

12:30 p.m.

...

Can I make another plea for the syntax following '@' to be an unrestricted expression? Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it.

1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language.

2) The restriction is in any case more apparent than real, as @ <any-expression> # disallowed, SyntaxError can be implemented, albeit in a more verbose aka less Pythonic was, as:

What makes you think that if something is 'more verbose' it is 'less pythonic'? I actually like the fact that python doesn't try condensing everything into one-liners and special symbols. I never really understood this need for being not verbose, but it does periodically come up on this list (and pretty much on every other programming list). Your fingers get tired? It takes too long to read an extra line? You are running out of space on your harddrive? It takes too long to transfer the source file over the network because of the extra line? Honestly, why do some people set for themselves the goal of "let's have as few characters in a source file as possible"? Cheers, Daniel

...

AnyExpr = <any-expression> @AnyExpr or as

def Identity(x): return x ... @Identity( <any-expression> ) # smuggle in as func arg

3) I propose the following as plausible use cases (I know other people will have their own):

3.1) @DecoratorList[index]

3.2) @DecoratorDictionary[key]

3.3) @Decorator1 if <condition> else Decorator2 # Special case of the last one: def Identity(x): return x @Decorator if __debug__ else Identity

Xavier Morel has pointed out that 3.1) can be implemented now as @DecoratorList.__getitem__[index] but this doesn't seem a good reason for forbidding the simpler syntax; after all Python allows the simpler syntax in other contexts. Similarly 3.2) can be written as @DecoratorDictionary.get(key)

(As an aside, perhaps a decorator that evaluates to None could be treated at run-time the same as no decorator, i.e. equivalent to the Identity function in the above examples. Currently it naturally raises TypeError: 'NoneType' object is not callable. Just a thought.)

Finally, sorry if I have not sent this e-mail to the right place (I wanted to attach it to the 'allow lambdas as decorators' thread but don't yet know how to do this). Also sorry that this partly duplicates a message I sent to python-dev. I am still finding my way round the Python mailing lists.

Best wishes Rob Cliffe

-- Psss, psss, put it down! - http://www.cafepress.com/putitdown

Mike Meyer

1:07 p.m.

On Sun, 6 Sep 2009 12:30:34 -0700 Daniel Fetchinson wrote:

...

What makes you think that if something is 'more verbose' it is 'less pythonic'? I actually like the fact that python doesn't try condensing everything into one-liners and special symbols.

Agreed. Readability, not succinctness, is what's pythonic. Being succinct usually - but not always - improves readability.

...

I never really understood this need for being not verbose, but it does periodically come up on this list (and pretty much on every other programming list). Your fingers get tired? It takes too long to read an extra line? You are running out of space on your harddrive? It takes too long to transfer the source file over the network because of the extra line?

Honestly, why do some people set for themselves the goal of "let's have as few characters in a source file as possible"?

Paul Graham (generally a very sharp guy) summarizes most of the reasons in http://www.paulgraham.com/power.html. I provide my attempt at a counterargument in http://www.mired.org/home/mwm/papers/readability.html. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Daniel Fetchinson

5:48 p.m.

...

...
What makes you think that if something is 'more verbose' it is 'less pythonic'? I actually like the fact that python doesn't try condensing everything into one-liners and special symbols.

Agreed. Readability, not succinctness, is what's pythonic. Being succinct usually - but not always - improves readability.

...
I never really understood this need for being not verbose, but it does periodically come up on this list (and pretty much on every other programming list). Your fingers get tired? It takes too long to read an extra line? You are running out of space on your harddrive? It takes too long to transfer the source file over the network because of the extra line?

Honestly, why do some people set for themselves the goal of "let's have as few characters in a source file as possible"?

Paul Graham (generally a very sharp guy) summarizes most of the reasons in http://www.paulgraham.com/power.html.

Thanks, this answers my question why people think this way. Although I'm still totally convinced that guys like Paul Graham, or anybody else who believes in shorter code, are misguided.

...

I provide my attempt at a counterargument in http://www.mired.org/home/mwm/papers/readability.html.

Yep, I more-or-less agree with you. Cheers, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown

Stephen J. Turnbull

7:13 p.m.

Daniel Fetchinson writes:

...

...
...
What makes you think that if something is 'more verbose' it is 'less pythonic'? I actually like the fact that python doesn't try condensing everything into one-liners and special symbols.

Yes.

...

...
Agreed. Readability, not succinctness, is what's pythonic. Being succinct usually - but not always - improves readability.

Yes.

...

...
...
I never really understood this need for being not verbose, but it does periodically come up on this list (and pretty much on every other programming list). Your fingers get tired?

Yes. See Jan Kaliszewski's post in the "possible attribute-oriented class" thread. His reasoning is valid, though I don't sympathize with it personally.

...

...
...
It takes too long to read an extra line?

Yes, when "too long" has the semantics "I read this repeatedly in a short space and don't need to see the whole thing over and over again. In fact, it gets in my way when reading an 'array' of the sme idiom." This is what Paul Graham means by (expressive) power, I believe. He mentions metrics like number of characters or lines, but he says what he really wants is something like the number of leaves in the AST. If the "this" is something local, then you use a function (or sometimes a macro if available) at that level of locality. But if the idiom appears across many programs, then it may be a good idea to turn it into a standard builtin, or even syntax. I believe this is the gist of Graham's argument, and it's very close to the criteria for adding syntax in the Zen (actually, the apocrypha, stuff like "not every three-line function needs to be a builtin" aren't canonized).

...

...
...
You are running out of space on your harddrive? It takes too long to transfer the source file over the network because of the extra line?

Both of those are silly. If you use compression, it will work out about the same anyway.<wink>

...

...
...
Honestly, why do some people set for themselves the goal of "let's have as few characters in a source file as possible"?

Mostly the ones who show up on Python lists don't have such a goal. They just want the ache in their hands and arms to go away, one unnecessary character at a time.

...

...
Paul Graham (generally a very sharp guy) summarizes most of the reasons in http://www.paulgraham.com/power.html.

Thanks, this answers my question why people think this way. Although I'm still totally convinced that guys like Paul Graham, or anybody else who believes in shorter code, are misguided.

...
I provide my attempt at a counterargument in http://www.mired.org/home/mwm/papers/readability.html.

Yep, I more-or-less agree with you.

But Paul Graham does, too, AFAICS. ISTM that what Paul G. doesn't get is that Paul P.'s epigram is more along the lines of Emerson's epigram. To put it in the same style, "A bogus succinctness is the hobgoblin of L2-cache-deprived minds (and RSI-hobbled wrists)." To me, the argument on "mired" seems quite complementary to the argument Graham makes, in that it shows how Python actually is succinct in the sense that Graham proposes, despite not minimizing character, token, or line counts.

Mike Meyer

7 Sep 7 Sep

12:05 a.m.

This appears to be veering way off topic... Except we're looking at what makes an idea "good" in python terms, vs. what makes them "not good". Basically, trying to define "pythonic". I don't know that that can be done, but there seem to be some broad points that can be agreed on....

...

...
...
...
Honestly, why do some people set for themselves the goal of "let's have as few characters in a source file as possible"? Mostly the ones who show up on Python lists don't have such a goal. They just want the ache in their hands and arms to go away, one unnecessary character at a time.

...
...
Paul Graham (generally a very sharp guy) summarizes most of the reasons in http://www.paulgraham.com/power.html.

Thanks, this answers my question why people think this way. Although I'm still totally convinced that guys like Paul Graham, or anybody else who believes in shorter code, are misguided.

...
I provide my attempt at a counterargument in http://www.mired.org/home/mwm/papers/readability.html.

I think my choice of "counterargument" here is a bit off. It's not all that argumentative.

...

...
Yep, I more-or-less agree with you. But Paul Graham does, too, AFAICS.

ISTM that what Paul G. doesn't get is that Paul P.'s epigram is more along the lines of Emerson's epigram. To put it in the same style, "A bogus succinctness is the hobgoblin of L2-cache-deprived minds (and RSI-hobbled wrists)." To me, the argument on "mired" seems quite complementary to the argument Graham makes, in that it shows how Python actually is succinct in the sense that Graham proposes, despite not minimizing character, token, or line counts.

What I was attempting to do was point out that succinctness for the sake of succinctness isn't necessarily a good thing. Python indeed tries to be succinct, but balances that against the need for the results to still be readable. I'd say that the mired.org document supplements what Paul G. had to say rather than complements it, as the mired.org document discusses areas where readability matters, which Paul G. ignored. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Scott David Daniels

8 Sep 8 Sep

2:46 p.m.

Mike Meyer wrote: ...

...

What I was attempting to do was point out that succinctness for the sake of succinctness isn't necessarily a good thing. Python indeed tries to be succinct, but balances that against the need for the results to still be readable.

I'm quite interested in this as well. I think that a Pythonic succinctness is very DRY (don't repeat yourself), rather than short. What I want when I read code is to be reading ideas, not typing or pasting. In Python, when I find I'm doing something several times I look for ways to combine tables and code, so what varies shows up clearly, and what is in common shows in the loop. APL was one language that battered me over the head with the proof that shorter was not necessarily clearer. --Scott David Daniels Scott.Daniels@Acm.Org

Carl Johnson

9 Sep 9 Sep

3:52 a.m.

On 2009/9/8 Scott David Daniels wrote:

...

APL was one language that battered me over the head with the proof that shorter was not necessarily clearer.

Ah yes, more proof of the adage: "if you can't be a good example, be a terrible warning." :-D — Carl Johnson

Steven D'Aprano

4:26 a.m.

On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:

...

APL was one language that battered me over the head with the proof that shorter was not necessarily clearer.

Conway's Game of Life in one line: http://www.catpad.net/michael/apl/ -- Steven D'Aprano

Lie Ryan

7:50 a.m.

Steven D'Aprano wrote:

...

On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:

...
APL was one language that battered me over the head with the proof that shorter was not necessarily clearer.

Conway's Game of Life in one line:

http://www.catpad.net/michael/apl/

Here is a hypothesis: "The length of a code is inversely proportional to the length of documentation required to explain the code" The APL Conway's Game of Life requires a full page of documentation to explain how it works. Most implementations of the same game have much less documentation and much longer code. Prove or disprove the hypothesis. If proven true, the hypothesis may lead to: The net worth of having a short, succinct code may be outweighed by the amount of documentation needed to explain the code.

George Sakkis

8:23 a.m.

On Wed, Sep 9, 2009 at 10:50 AM, Lie Ryan wrote:

...

Steven D'Aprano wrote:

...
On Wed, 9 Sep 2009 07:46:09 am Scott David Daniels wrote:

...
APL was one language that battered me over the head with the proof that shorter was not necessarily clearer.

Conway's Game of Life in one line:

http://www.catpad.net/michael/apl/

Here is a hypothesis: "The length of a code is inversely proportional to the length of documentation required to explain the code"

The APL Conway's Game of Life requires a full page of documentation to explain how it works. Most implementations of the same game have much less documentation and much longer code.

Prove or disprove the hypothesis.

If proven true, the hypothesis may lead to: The net worth of having a short, succinct code may be outweighed by the amount of documentation needed to explain the code.

Any such proof or even discussion should take into account what the primitives (atoms and allowed operations) are. If not, here is a solution that is short both in code and documentation: game_of_life().solve() ;-) George

Greg Ewing

5:52 p.m.

George Sakkis wrote:

...

Any such proof or even discussion should take into account what the primitives (atoms and allowed operations) are.

Probably you should include the size of the documentation of the primitives used in your programming language manual, any other well-known literature they implicitly refer to, etc.

...

If not, here is a solution that is short both in code and documentation:

game_of_life().solve()

But then you need to go and find a paper describing the game of life and the algorithm being used to solve it and include its length! -- Greg

Yuvgoog Greenle

6:40 p.m.

You can drop the game of life manual, it would be needed in any implementation so it doesn't help in describing the function documentation_length(code_length)... Aside from a constant value. d - documentatin_length the amount of words or symbols. c - code_length in words or symbols. d = K*c + A Lets approximate: brainfuck K = 30 APL K = 20 perl K = 2 python K = 0.5 K is the obfuscation factor (anti-readability). The constant A is needed because if you didn't write any code you're still gonna have some explaining to do. For a given algorithm with a complexity of L logical nodes, here's the inverse relation Ryan was talking about.: L = d * c * Rd * Rc As you can see for a given algorithm with a constant L, as d grows, c shrinks. R is the richness of the language, if we have more words in our language, less words are needed to describe things. Rd is the richness of the documentation language (english) and Rc is the richness of the code-language. I think there might be some unit problems so I'm gonna let someone else clean up and complete the equations. Good night. On Thu, Sep 10, 2009 at 3:52 AM, Greg Ewing wrote:

...

George Sakkis wrote:

Any such proof or even discussion should take into account what the

...
primitives (atoms and allowed operations) are.

Probably you should include the size of the documentation of the primitives used in your programming language manual, any other well-known literature they implicitly refer to, etc.

If not, here is a

...
solution that is short both in code and documentation:

game_of_life().solve()

But then you need to go and find a paper describing the game of life and the algorithm being used to solve it and include its length!

-- Greg

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

-- Yuv hzk.co.il

Brett Cannon

6 Sep 6 Sep

1:18 p.m.

On Sun, Sep 6, 2009 at 09:41, Rob Cliffe wrote:

...

Can I make another plea for the syntax following '@' to be an unrestricted expression? Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it.

When it comes to Guido's gut, a rationalization isn't needed. Perk of being BDFL. Plus his gut is right so often it tends to not be questioned.

...

1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language.

It's not difficult to explain; decorators can only be a dotted name w/ an optional method call and its corresponding arguments. It keeps the syntax simple and clean, IMO. Decorators add a mental overhead of having to think about what they will do to a function when reading the code. If I then also have to figure out what an arbitrary expression evaluates to in order to figure that out that is more mental effort than needed. Yes, you can do whatever with the decorator you are passing in, but hopefully you are not so evil/stupid as to make a decorator that copmlicated. Give people the power of full expressions and that will happen more often.

...

2) The restriction is in any case more apparent than real, as     @ <any-expression> # disallowed, SyntaxError can be implemented, albeit in a more verbose aka less Pythonic was, as:

    AnyExpr = <any-expression>     @AnyExpr

or as

    def Identity(x): return x      ...     @Identity( <any-expression> ) # smuggle in as func arg

And we almost ditched lambdas in Python 3 because you can implement them in the same way. The only reason they got to stick around was they were already in use and people threw a fit over them.

...

3) I propose the following as plausible use cases (I know other people will have their own):

3.1)     @DecoratorList[index]

3.2)     @DecoratorDictionary[key]

3.3)     @Decorator1 if <condition> else Decorator2 #   Special case of the last one:     def Identity(x): return x     @Decorator if __debug__ else Identity

Plausible does not equal useful. You need to show that this actually comes up in normal coding for a decent amount of Python code to warrant tweaking the language over.

...

Xavier Morel has pointed out that 3.1) can be implemented now as @DecoratorList.__getitem__[index] but this doesn't seem a good reason for forbidding the simpler syntax; after all Python allows the simpler syntax in other contexts. Similarly 3.2) can be written as @DecoratorDictionary.get(key)

(As an aside, perhaps a decorator that evaluates to None could be treated at run-time the same as no decorator, i.e. equivalent to the Identity function in the above examples. Currently it naturally raises TypeError: 'NoneType' object is not callable. Just a thought.)

That's not going to happen. =) Complicates the bytecode unnecessarily. Once again, this needs to actually come up in regular usage to warrant even considering the change.

...

Finally, sorry if I have not sent this e-mail to the right place (I wanted to attach it to the 'allow lambdas as decorators' thread but don't yet know how to do this). Also sorry that this partly duplicates a message I sent to python-dev. I am still finding my way round the Python mailing lists.

No, this is the place to send thought out proposals for changing Python before they get promoted to hitting python-dev. -Brett

Nick Coghlan

1:44 p.m.

Brett Cannon wrote:

...

On Sun, Sep 6, 2009 at 09:41, Rob Cliffe wrote:

...
Can I make another plea for the syntax following '@' to be an unrestricted expression? Guido has said he has a 'gut feeling' against this but has not as far as I know rationalised it.

When it comes to Guido's gut, a rationalization isn't needed. Perk of being BDFL. Plus his gut is right so often it tends to not be questioned.

...
1) It is inconsistent with Python in general (unPythonic) to impose arbitrary restrictions in one particular place, and hard to explain to someone learning the language.

It's not difficult to explain; decorators can only be a dotted name w/ an optional method call and its corresponding arguments.

...

From the last discussion, I believe Guido was actually amenable to the idea of extending this to allow a subscript operation as well, so a decorator could be pulled from a sequence or map of decorators without requiring an otherwise unnecessary function call.

So what's needed at this point is for someone that is bothered by the restriction to come up with a patch to loosen the restriction without getting rid of it entirely. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

5341

Age (days ago)

5345

Last active (days ago)

List overview

Download

14 comments

13 participants

participants (13)

Brett Cannon
Carl Johnson
Daniel Fetchinson
George Sakkis
Greg Ewing
Lie Ryan
Mike Meyer
Nick Coghlan
Rob Cliffe
Scott David Daniels
Stephen J. Turnbull
Steven D'Aprano
Yuvgoog Greenle

Decorator syntax restriction

Mike Meyer

Mike Meyer

Carl Johnson

tags

participants (13)