Description

serhiy-storchaka

opened on Sep 30, 2018

Issue body actions

BPO	34856
Nosy	@gvanrossum, @rhettinger, @terryjreedy, @serhiy-storchaka, @tirkarthi
PRs	gh-79037: Add signature and body expression to the repr of lambda #9647

^{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

1. serhiy-storchaka commented on Sep 30, 2018

   

   serhiy-storchaka

   on Sep 30, 2018

   MemberAuthor

   More actions

   >>> 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>".
2. serhiy-storchaka

   added

   3.8 (EOL)end of lifeend of life

   interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)

   type-featureA feature request or enhancementA feature request or enhancement

   on Sep 30, 2018
3. gvanrossum commented on Sep 30, 2018

   

   gvanrossum

   on Sep 30, 2018

   Member

   More actions

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

   On Sun, Sep 30, 2018 at 11:31 AM Serhiy Storchaka <[email protected]>
   wrote:

   Change by Serhiy Storchaka <[email protected]>:

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

   ---

   Python tracker <[email protected]>
   <https://bugs.python.org/issue34856\>

   ---

   --
   --Guido (mobile)
4. terryjreedy commented on Oct 5, 2018

   

   terryjreedy

   on Oct 5, 2018

   Member

   More actions

   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.
5. terryjreedy

   changed the title [-]Make the repr of lambda containing the signature and body expression.[/-] [+]Make the repr of lambda contain signature and body expression.[/+] on Oct 5, 2018
6. serhiy-storchaka commented on Oct 5, 2018

   

   serhiy-storchaka

   on Oct 5, 2018

   MemberAuthor

   More actions

   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>.
7. gvanrossum commented on Oct 5, 2018

   

   gvanrossum

   on Oct 5, 2018

   Member

   More actions

   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.
8. rhettinger commented on Oct 5, 2018

   

   rhettinger

   on Oct 5, 2018

   Contributor

   More actions

   +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.
9. gvanrossum commented on Oct 6, 2018

   

   gvanrossum

   on Oct 6, 2018

   Member

   More actions

   OK, if it gets truncated beyond a reasonable length I remove my objection.
10. terryjreedy commented on Oct 22, 2018

    

    terryjreedy

    on Oct 22, 2018

    Member

    More actions

    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.
11. ezio-melotti

    transferred this issue fromon Apr 10, 2022

Issue actions