[Python-ideas] @return?

MRAB python at mrabarnett.plus.com
Wed Apr 14 20:41:58 CEST 2010


Masklinn wrote:
> On 14 Apr 2010, at 18:41 , Conrad Irwin wrote
>> On 04/14/2010 03:54 PM, spir ☣ wrote:
>>> On Wed, 14 Apr 2010 01:23:08 +0100
>>> 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
>> As I understand it, there is little desire to allow function definitions
>> to appear "just anywhere" in Python.
> 
> I don't believe that's true, but it is possible that people who express
>  this desire are directed towards other languages.
> 
> I can only speak for myself when I say that I'd kill for full-fledged 
> anonymous defs (uncrippled lambdas, whatever you call them) in Python,
> but the desire is most definitely there.
> 
Part of the problem is finding a suitable syntax. Python's use of
indentation makes it difficult, and we don't want to give that up, do
we? :-)



More information about the Python-ideas mailing list