Closed guyarad closed 3 years ago
The expectation I have with repr()
is that if you are going to return a string representation that can be converted back into a Python object, that it be a faithful representation of the original. With the ObjectProxy
, not sure one could guarantee that with the proxy object also being recreated, so only provide the cryptic reference. Plus when debugging, not seeing the object proxy type and only seeing what was wrapped would be mighty confusing as you wouldn't be able to see if the proxy was actually there or not.
I found myself needing the proxy when using SqlAlchemy. I was sub-classing the PostgreSQL ENUM object.
Apparently, when auto generating a migration script, alembic was using repr
to generate code, which resulted with bad syntax.
Obviously the fix was quick and easy.
I understand your reasoning, but I believe that if you're debugging you should know what you are doing (you can always use type
), and expected ObjectProxy
to be fully transparent.
I'm going to leave it to you - feel free to close it as "by design". If you think it should be fixed, I would be happy to contribute and create a PR.
Going to close this issue. The intent always was with ObjectProxy
is that if you need repr()
to return a representation that can be used to recreate the object, or even show the wrapped version, you need to override __repr__()
in your custom ObjectProxy
derived class.
From examine the code it's obviously intentional, but had I chose to use the ObjectProxy, why not proxying
__repr__
as well? This is more of a discussion item rather than an issue, but couldn't find anywhere to pose this question. Feel free to point me to it... Thanks for your awesome library (and blog posts)!