Repository navigation
Make the repr of lambda contain signature and body expression. #79037
Description
| BPO | 34856 |
|---|---|
| Nosy | @gvanrossum, @rhettinger, @terryjreedy, @serhiy-storchaka, @tirkarthi |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = None
closed_at = None
created_at = <Date 2018-09-30.18:14:23.113>
labels = ['interpreter-core', 'type-feature', '3.8']
title = 'Make the repr of lambda contain signature and body expression.'
updated_at = <Date 2018-10-22.19:26:54.089>
user = 'https://github.com/serhiy-storchaka'bugs.python.org fields:
activity = <Date 2018-10-22.19:26:54.089>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2018-09-30.18:14:23.113>
creator = 'serhiy.storchaka'
dependencies = []
files = []
hgrepos = []
issue_num = 34856
keywords = ['patch']
message_count = 8.0
messages = ['326738', '326747', '327179', '327181', '327183', '327202', '327205', '328271']
nosy_count = 5.0
nosy_names = ['gvanrossum', 'rhettinger', 'terry.reedy', 'serhiy.storchaka', 'xtreak']
pr_nums = ['9647']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34856'
versions = ['Python 3.8']Reacted by Jeffrey Bosboom
Activity
serhiy-storchaka commentedon Sep 30, 2018
Currently it is less informative: "<function <lambda> at 0x7f437cd27890>".
gvanrossum commentedon Sep 30, 2018
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:
--
--Guido (mobile)
terryjreedy commentedon Oct 5, 2018
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.
[-]Make the repr of lambda containing the signature and body expression.[/-][+]Make the repr of lambda contain signature and body expression.[/+]serhiy-storchaka commentedon Oct 5, 2018
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>.
gvanrossum commentedon Oct 5, 2018
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.
rhettinger commentedon Oct 5, 2018
+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.
gvanrossum commentedon Oct 6, 2018
OK, if it gets truncated beyond a reasonable length I remove my objection.
terryjreedy commentedon Oct 22, 2018
My understanding of the current code is that in the example above, f.__name__ would be "<lambda x, y=1: x + y>".
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.
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.