python / cpython

The Python programming language
https://www.python.org
Other
62.32k stars 29.94k forks source link

Make the repr of lambda contain signature and body expression. #79037

Open serhiy-storchaka opened 5 years ago

serhiy-storchaka commented 5 years ago
BPO 34856
Nosy @gvanrossum, @rhettinger, @terryjreedy, @serhiy-storchaka, @tirkarthi
PRs
  • python/cpython#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: ```python assignee = None closed_at = None created_at = labels = ['interpreter-core', 'type-feature', '3.8'] title = 'Make the repr of lambda contain signature and body expression.' updated_at = user = 'https://github.com/serhiy-storchaka' ``` bugs.python.org fields: ```python activity = actor = 'terry.reedy' assignee = 'none' closed = False closed_date = None closer = None components = ['Interpreter Core'] creation = 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'] ```

    serhiy-storchaka commented 5 years ago
    >>> 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>".

    gvanrossum commented 5 years ago

    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)

    terryjreedy commented 5 years ago

    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.

    serhiy-storchaka commented 5 years ago

    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 commented 5 years ago

    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 commented 5 years ago

    +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 commented 5 years ago

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

    terryjreedy commented 5 years ago

    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.