osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Syntax for one-line "nonymous" functions in "declaration style"


Re: ">> Neither i like how a function magically turns into a generator if the 
>> keyword `yield` appears somewhere within its definition.

> I agree, there should have been a required syntactic element on the "def"
> line as well to signal it immediately to the reader. It won't stop me from using them, though."

One way to save people looking at the code from having to look through a function for a yield statement to see if it is a generator would be to add a """doc string""" immediately after the function def, saying that it is a generator
and describing what it does.  I realize I'm calling on the programmer to address this issue by adding doc strings.  Nonetheless adding doc strings is a good habit to get in to.
--- Joseph S.
-----Original Message-----
From: Ian Kelly <ian.g.kelly at gmail.com> 
Sent: Sunday, March 31, 2019 3:45 PM
To: Python <python-list at python.org>
Subject: Re: Syntax for one-line "nonymous" functions in "declaration style"

On Sun, Mar 31, 2019 at 1:09 PM Alexey Muranov <alexey.muranov at gmail.com>
wrote:
>
> On dim., Mar 31, 2019 at 6:00 PM, python-list-request at python.org wrote:
> > On Sat, Mar 30, 2019, 5:32 AM Alexey Muranov 
> > <alexey.muranov at gmail.com>
> > wrote:
> >
> >>
> >>  On ven., Mar 29, 2019 at 4:51 PM, python-list-request at python.org
> >> wrote:
> >>  >
> >>  > There could perhaps be a special case for lambda expressions 
> >> such  >  that,  > when they are directly assigned to a variable, 
> >> Python would use the  > variable name as the function name. I 
> >> expect this could be  >  accomplished by  > a straightforward 
> >> transformation of the AST, perhaps even by just  >  replacing  > 
> >> the assignment with a def statement.
> >>
> >>  If this will happen, that is, if in Python assigning a 
> >> lambda-defined  function to a variable will mutate the function's 
> >> attributes, or else,  if is some "random" syntactically-determined 
> >> cases
> >>
> >>      f = ...
> >>
> >>  will stop being the same as evaluating the right-hand side and  
> >> assigning the result to "f" variable, it will be a fairly good 
> >> extra  reason for me to go away from Python.
> >>
> >
> > Is there a particular reason you don't like this? It's not too 
> > different from the syntactic magic Python already employs to support 
> > the 0-argument form of super().
>
> I do not want any magic in a programming language i use, especially if 
> it breaks simple rules.
>
> I do not like 0-argument `super()` either, but at least I do not have 
> to use it.

Well, you wouldn't have to use my suggestion either, since it only applies to assignments of the form "f = lambda x: blah". As has already been stated, the preferred way to do this is with a def statement. So just use a def statement for this, and it wouldn't affect you (unless you *really* want the function's name to be "<lambda>" for some reason).

That said, that's also the reason why this probably wouldn't happen. Why go to the trouble of fixing people's lambda assignments for them when the preferred fix would be for them to do it themselves by replacing them with def statements?

> Neither i like how a function magically turns into a generator if the 
> keyword `yield` appears somewhere within its definition.

I agree, there should have been a required syntactic element on the "def"
line as well to signal it immediately to the reader. It won't stop me from using them, though.