[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

repr = expression representation?

Christian Gollwitzer <auriocus at gmx.de> writes:

> Am 17.05.19 um 06:13 schrieb Stefan Ram:   However, look at this
>> |>>> print( str( print ))
>> |<built-in function print>
>> |>>> print( repr( print ))
>> |<built-in function print>
>>    . While it is nice that ?str( print )? gives some useful
>>    information, I would expect ?repr( print )? to give
>>    ?print? - 
> This is impossible. Python does not use "call by name", so a function
> cannot know how the argument is called in the upper stack
> level. Consider:
> Apfelkiste:inotes chris$ python3
> Python 3.6.1 |Anaconda 4.4.0 (x86_64)| (default, May 11 2017, 13:04:09)
> [GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
>>>> blafasel = print
>>>> print(repr(blafasel))
> <built-in function print>

I don't think that renaming is important to SR.  The result should be,
in his view, a string representing the /value/ of the argument to repr,
so repr(print) and replr(blafasel) could both return the same (as they
indeed do) thing and I think he'd be happy.

> You'll have to accept that not all Python objects can be represented
> as literals.

I don't think SR minds if the result is not a literal.  I think the hope
was simply that eval(repr(E)) === E for any expression E.  You could, in
a very limited way, fudge it like this:

def myrepr(e):
    if isinstance(e, types.BuiltinFunctionType):
        return e.__name__
    return repr(e)

The trouble is that print does not always mean print because that
identifier can be rebound.  Python could try to provide some /other/
name for every object, one that can't be rebound (something like an
environment + string lookup) but it's probably not worth it.