[Python-ideas] Repr of lambda

[Franklin? Lee]

On Mon, Dec 18, 2017 at 8:31 AM, Steve Barnes <gadgetsteve at live.co.uk> wrote:
>
> On 18/12/2017 11:43, Steven D'Aprano wrote:
>> On Mon, Dec 18, 2017 at 07:54:17AM +0000, Steve Barnes wrote:
>>
>>> Isn't this exactly the sort of information already available via
>>> inspect.getardspec, inspect.getsourcelines & inspect.getsource?
>>
>> [snip ipython interactive session showing that the answer is "Yes"]
>>
>> You answered your own question: yes it is. What's your point? That's not
>> a rhetorical question -- I genuinely don't understand why you raise
>> this. Do you see the existence of inspect.* as negating the usefulness
>> of giving functions a more useful repr? As proof that the information is
>> available? Something else?

Wow, that's way too aggressive for this list.

> Hi Steve,
>
> I see it as showing that the information is already available to anybody
> who needs it so I question the usefulness of changing repr (for
> everybody) which is bound to break something somewhere. Now if you were
> to suggest adding a verbose flag to repr or a print format, maybe both -
> so that people don't have to import inspect then I would say that you
> have a lot less chance of breaking any code/test cases that is in the wild.
>
> Sorry I should have made my point(s) clearer.

But is it readily available? Will the people who need the information
know how to get it? No. IMO, `inspect` is somewhat arcane, and you
shouldn't need its full power to use lambdas.

Right now, lambdas are represented just by their memory location.
That's not meaningful. Lambdas are, abstractly speaking, value
objects, with value defined by its definition (including parameter
names). (That's not really true in Python, where lambdas are not
compared by just function definition.) A lambda's location is
irrelevant to its functionality; unless you poke around its dunder
bits, a lambda's functionality is completely determined by its
signature, its body, and the closure. In short, the address doesn't
really represent the lambda.

Imagine a world where ints and strs are represented by type and
address. That's not an ideal world. How you use an int or str has
nothing to do with its memory location, and everything to do with its
value.

Regarding backward compatibility, I'm unsympathetic toward anyone who
was relying on lambdas being represented by their addresses. At worst,
they'd check for `repr(f).startswith('<function <lambda>')`, which, if
we really care, can be accounted for. I'm more concerned with future
backward compatibility: if the repr is made meaningful now, it will
definitely be harder to change in the future. In any case, it should
be more a consideration than a reason against.

Note that it's impossible in general to fulfill `eval(repr(myLambda))
== myLambda`, because of how lambdas are compared, but also because
you won't necessarily have access to the same lexical scope as the
original lambda, and because default arguments can hold state.