Hi Terry, On Fri, Aug 2, 2013 at 12:29 AM, Terry Reedy <tjre...@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 <tjre...@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 <tjre...@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 <tjre...@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 <tjre...@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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kxepal%40gmail.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
