[Python-Dev] PEP 8 modernisation (original) (raw)

Alexander Shorin kxepal at gmail.com
Fri Aug 2 09:28:46 CEST 2013

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 at 0x000000000227F730>, # 'mul': <function 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

More information about the Python-Dev mailing list