![](https://secure.gravatar.com/avatar/ab17526562757775bb8a71f1a415aaf4.jpg?s=120&d=mm&r=g)
On Mon, Dec 18, 2017 at 8:31 AM, Steve Barnes <gadgetsteve@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.