Lambda was almost removed in Python 3.

>
> Using `dict` to store lambdas:
>
> > op = { 'add': lambda x,y: x*y, 'mul': �lambda x, y: x+y}
>
> Shows the hack to bypass PEP8 guides. Do you like to see code above instead of:
>
> add = lambda x,y: x*y
> mul = lambda x, y: x+y
>
> Probably, I don't since dict is a blackbox and I have to check things
> first before use them.

People are free to write their own style guides that disagree with pep 8 (a point which is now made explicitly in the PEP).

>
> Disclaimer: �I don't try to stand for lambdas, I'm not using them
> everywhere in my code, but I'd like to know answer for the question
> "Why lambdas?". Currently, it is "Handy shorthand functions - use them
> free", but with new PEP-8 statement I really have to think like
> "Lambdas? Really, why?".

Use them for an anonymous function as an expression. All PEP 8 is now saying is that giving a lambda a name is to completely misunderstand what they're for.

Cheers,
Nick.

">

(original) (raw)


On 2 Aug 2013 17:31, "Alexander Shorin" <kxepal@gmail.com> wrote:
\>
\> Hi Terry,
\>
\> On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy <tjreedy@udel.edu> wrote:
\> > def f(x): return 2\*x
\> > f = lambda x: 2\*x
\> > Three spaces is seldom a crucial difference. If the expression is so long it go past the limit (whatever we decide it is), it can be wrapped.
\>
\> and if I have multiple lambda-like def\`s it will hit the PEP rule :
\>
\> > While sometimes it's okay to put an if/for/while with a small body on the same line, never do this for multi-clause statements. Also avoid folding such long lines!
\>
\> On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy <tjreedy@udel.edu> wrote:
\> >> and/or to remove duplicates (especially for sorted groupby case)?
\> > I do not understand this.
\>
\> See \[Python-Dev\] Lambda \[was Re: PEP 8 modernisation\] thread for example:
\> http://mail.python.org/pipermail/python-dev/2013-August/127715.html
\>
\> On Fri, Aug 2, 2013 at 12:35 AM, Terry Reedy <tjreedy@udel.edu> wrote:
\> >> I understand this, but I'm a bit confused about fate of lambdas with
\> >> such guideline since I see no more reasons to use them with p.9
\> >> statement: long lines, code duplicate, no mock and well tests etc. -
\> >> all these problems could be solved with assigning lambda to some name,
\> >> but now they are looks useless (or useful only for very trivial cases)
\> >
\> >I do not understand most of that, but...
\> >The guideline is not meant to cover passing a function by parameter name. �mylist.sort(key=lambda x: x\[0\]) is still ok. Does "Always use a def statement >instead of assigning a lambda expression to a name." need 'in an assignment statement' added?

>

> I wrote about that lambda`s use case become too small to use them in

> real code. If they are dishonoured - need to write so and clearly, but

> not limiting their use cases step by step till every Python devs will

> think like "Lambdas? Why? Remove them!".

Lambda was almost removed in Python 3.

>
\> Using \`dict\` to store lambdas:
\>
\> > op = { 'add': lambda x,y: x\*y, 'mul': �lambda x, y: x+y}
\>
\> Shows the hack to bypass PEP8 guides. Do you like to see code above instead of:
\>
\> add = lambda x,y: x\*y
\> mul = lambda x, y: x+y
\>
\> Probably, I don't since dict is a blackbox and I have to check things
\> first before use them.

People are free to write their own style guides that disagree with pep 8 (a point which is now made explicitly in the PEP).

>
\> Disclaimer: �I don't try to stand for lambdas, I'm not using them
\> everywhere in my code, but I'd like to know answer for the question
\> "Why lambdas?". Currently, it is "Handy shorthand functions - use them
\> free", but with new PEP-8 statement I really have to think like
\> "Lambdas? Really, why?".

Use them for an anonymous function as an expression. All PEP 8 is now saying is that giving a lambda a name is to completely misunderstand what they're for.

Cheers,
Nick.