Christian Gollwitzer <aurio...@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.
<cut>
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
