This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients Arfrever, barry, benjamin.peterson, eric.snow, hodgestar, lukasz.langa, pitrou, python-dev, rhettinger, robagar, serhiy.storchaka
Date 2017-09-12.19:45:40
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1634303.L1ICABa5sc@saraksh>
In-reply-to <>
> The recursion case was successfully deep copying under Python 2. When
> migrating the code, the sudden recursion error is pretty hard to debug.

Python 3 is not compatible with Python 2 because it fixes many bugs that can't 
be fixed without breaking backward compatibility. This is a one of such cases.

The problem with copying is not the only problem with that class. It also has 
problems when the garbage collector breaks reference loops and sets instance 
attributes to None. The idiomatic ways of solving these problems is accessing 
to proxied_object as self.__dict__['proxied_object'] or setting a class 
attribute proxied_object = None. We had fixed a number of similar issues in the 

> Right, but during migration from Python 2 to Python 3 the error message is
> nowhere close suggesting what the correct behavior is.

I think a traceback should help to identify the problem. At least it looks 
pretty clear to me.

> My patch doesn't change anything here. It simply causes special methods to
> be reported as not present instead of raising exceptions from within
> __getattr__.

And this is a regression change. Instead of not producing incorrect data, the 
code now poduces it.

Yet one drawback is a performance regression. Additional checks slow down a 

> > Your patch reintroduces similar bug in copy.
> No, my patch introduces a getattr() equivalent for deepcopy which is robust
> against random exceptions raised from __getattr__.

The code shouldn't be tolerant to random exceptions raised from __getattr__. 
Exceptions signal about a bug in user code.

> * make code that worked on Python 2 (even if clowny) not fail on Python 3,
> adding to the migration burden;

Raising an exception is a feature of Python 3, not a bug. It helps to catch 
programming errors in user code.

> Clearly the current workaround I wrote doesn't go in the direction you'd
> like to see.  Do you have a suggestion of an approach that would be better?
>  I can implement it.

The current behavior LGTM. I don't think it needs to be improved.
Date User Action Args
2017-09-12 19:45:40serhiy.storchakasetrecipients: + serhiy.storchaka, barry, rhettinger, pitrou, benjamin.peterson, hodgestar, Arfrever, lukasz.langa, python-dev, eric.snow, robagar
2017-09-12 19:45:40serhiy.storchakalinkissue16251 messages
2017-09-12 19:45:40serhiy.storchakacreate