[Python-ideas] @return?

spir ☣ denis.spir at gmail.com
Wed Apr 14 16:54:21 CEST 2010


On Wed, 14 Apr 2010 01:23:08 +0100
Conrad Irwin <conrad.irwin at googlemail.com> wrote:

> > You might be interested in Michele Simionato's excellent decorator package.
> > The above could be written:
> > 
> > import decorator
> > def my_decorator(func):
> >     return decorator.decorator(func, lambda: func(modulate(args)))
> >   
> 
> Of course, everything is more succinct when a lambda can be used instead
> of defining a new function; my proposal was to deal with the times when
> this shorthand is not available.

Well, i'm not 100% sure of the point of view below, but let's take the risk ;-) (Gentle)critics welcome.

As I see it, the issue you raise is more general than the precise point of a decorator's return value. It is instead deeply rooted in Python's core syntax making func/method  definitions (and classes, too) somewhat different. One doesn't write:

f = function(): <body>

So that one cannot write neither:

return function(): <body>

This point (together with the unneeded 'return' in this case) also raises the need for a special inline syntax for func defs used in higher-order functions --say for programming in functional style. This a bit of a pity because Python also offers a third syntax for similar semantics with list comprehensions.

As a counter-example just for reference, Lua's function defs are normal definitions, so that there are no such issues; "return function() <body>" is perfectly valid and even common; there is no need for special inline syntax.
But:
* An alternate pattern (function f() <body>) is available for named functions, while unnecessary (I personly never use it).
* Mainly because of the useless 'return', I guess, some users still argue for a more compact anonymous pattern.


Denis
________________________________

vit esse estrany ☣

spir.wikidot.com



More information about the Python-ideas mailing list