On Thu, 2 Mar 2000, Greg Stein wrote:
> On Thu, 2 Mar 2000, Guido van Rossum wrote:
> >...
> > But it is just as likely that calling __del__ on a partially
> > uninitialized object is a bad mistake, and I am doing all these cases
> > a favor by not calling __del__ when __init__ failed!
> >
> > Any opinions? If nobody speaks up, I'll make the change.
>
> +1 on calling __del__ IFF __init__ completes successfully.
That would be my vote as well.
What convinced me of this is the following:
If it's up to the implementation of __del__ to deal with a problem
that happened during initialization, you only know about the problem
with very coarse granularity. It's a pain (or even impossible) to
then rediscover the information you need to recover adequately.
If on the other hand you deal with the problem in __init__, then
you have much better control over what is happening, because you
can position try/except blocks precisely where you need them to
deal with specific potential problems. Each block can take care
of its case appropriately, and re-raise if necessary.
In general, it seems to me that what you want to do when __init__
runs afoul is going to be different from what you want to do to
take care of object cleanup in __del__. So it doesn't belong
there -- it belongs in an except: clause in __init__.
Even though it's an incompatibility, i really think this is the
right behaviour.
-- ?!ng
"To be human is to continually change. Your desire to remain as you are
is what ultimately limits you."
-- The Puppet Master, Ghost in the Shell
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4