>>> f = lambda x, y=1: x+y
>>> f
<lambda x, y=1: x + y at 0x7f437cd27890>

Currently it is less informative: "<function <lambda> at 0x7f437cd27890>".

OTOH the current repr is bounded. Some people write very long lambdas.

On Sun, Sep 30, 2018 at 11:31 AM Serhiy Storchaka <report@bugs.python.org>
wrote:

Change by Serhiy Storchaka <storchaka+cpython@gmail.com>:

----------
keywords: +patch
pull_requests: +9039
stage: -> patch review

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue34856\>

---

--
--Guido (mobile)

Right. Like printing an ascii text version of the Mandelbrot set in one 20-line lambda + call expression statement. Let's truncate to, say, 40 chars. This should cover a large majority of lambda expressions.

People write also long strings, lists, dicts, but they are not truncated. In contrary to the above types which usually are created programmically and can be very large, lambdas are written manually and rarely exceed the size of a single line. We should discourage writing long lambdas. Local named functions are more appropriate for this. Although some people can use very long function names...

Actually the repr of lambda can be very long now: <function VeryLongClassName.very_long_method_name.<locals>.<lambda> at 0x7fa2d9e04338>.

However, this is a compatibility liability. People routinely use various
formatting options to truncate long strings, since experience shows those
are common. But few people expect the repr() of a function/lambda object to
be unwieldy.

+0 This would help with debugging and would compensate for the lack of a docstring. FWIW, I've found the new longer repr's for regex match objects to be helpful, and this would be another step in the right direction.

Terry's suggestion to truncate a long repr makes sense. The repr's for long lists and dicts are different in that they are expected to round-trip, but there is no such expectation for lambdas.

OK, if it gets truncated beyond a reasonable length I remove my objection.

My understanding of the current code is that in the example above, f.__name__ would be "<lambda x, y=1: x + y>".

1. I believe this would make the representation
   <<lambda x, y=1: x + y> at 0x........>
   unless functions gain a custom __repr__ method that strips the brackets off the name when present. I don't really like the alternative of leaving the brackets off the name.

2. My proposal is to limit the length of the .__name__ attribute. This not only limits the repr but also the function name part of traceback lines. I consider the latter more important as I personally see function names in tracebacks far more often than in representations. Long function names wrapped to several lines would in my opinion negatively affect tracebacks. Large collections do not affect tracebacks.