Message198233
| Author |
chortos |
| Recipients |
Arfrever, chortos, gvanrossum, petri.lehtinen, pitrou, python-dev, r.david.murray, serhiy.storchaka, terry.reedy, vstinner |
| Date |
2013年09月21日.23:54:41 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1379807681.56.0.0168340356108.issue12085@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> But what about the self.returncode data attribute? Should we also add a
> class 'returncode' attribute? If so, what should be its value? None? or
> object()? Or is it guaranteed that when _child_created is set true,
> returncode will be defined, so that a class attribute is not needed?
For what it's worth, returncode is indeed guaranteed to be defined when _child_created is True: it is initialized in __init__ before _execute_child is run. Of course, this does not help the general case of __del__ methods in other classes.
Silencing all AttributeErrors in all __del__ calls may be an easy and generic solution, but it will also hide genuine logic errors. I think it is reasonable to expect classes with __del__ to be careful about using attributes that exist, just like they must be careful about performing high-level operations that are valid in whatever state the object might be: destroy/close only things that have been created/opened, undo only actions that have been done etc. |
|