[Python-Dev] PEP 8 modernisation

[Alexander Shorin]

Hi Terry,

On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy <tjreedy at 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 at 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 at 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!".

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.

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?".

P.S.

On Thu, Aug 1, 2013 at 3:36 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Please stop both the top-posting and the FUD.

Sorry, different ML, different rules. You know mail client with allows
to have per-address reply setting? I don't, but would like to see your
suggestions in private answer. Thanks.
--
,,,^..^,,,


On Fri, Aug 2, 2013 at 12:56 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 8/1/2013 11:35 AM, Alexander Belopolsky wrote:
>
>> Here is one use-case where .. =  lambda .. cannot be replaced with def ..
>>
>> op['add'] = lambda x,y: x+y
>> op['mul'] = lambda x, y: x*y
>
>
> Yes, you are binding the functions to named slots, not to names, so not
> covered by the PEP. Once might still want to replace the expressions
> themselves, at the cost of more typing, for the advantage of better
> representations.
>
> op = { 'add': lambda x,y: x*y, 'mul':  lambda x, y: x+y}
> print(op)  # no apparent problem
> # {'add': <function <lambda> at 0x000000000227F730>,
> # 'mul': <function <lambda> at 0x00000000033867B8>}
>
> def add(x, y): return x + y
> def mul(x, y): return x * y
> # These can be unittested individually
>
> op = {'add': mul, 'mul': add}  # mistake easily seen in original code
> print(op)
> # {'add': <function mul at 0x0000000003440950>,
> # 'mul': <function add at 0x00000000034408C8>}
> # problem apparent to user who import this object and prints it when code
> fails
>
> If op has 20 such functions, names become even more of an advantage
>
> --
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/kxepal%40gmail.com