Since it's already possible for __del__-containing cycles
to survive interpreter shutdown, I don't see that this
issue ought to be a showstopper for elimination of module
clearing.
Also, it seems to me that the kind of cycles module
clearing is designed to break, i.e. those between classes,
funct
> By "revive cycles", I mean make sure that they are referenced by an
> independent referrer (one that won't go away as part of the __del__
> calling process).
I think this is a) unfortunate terminology (as the cycle is not dead,
so no need to revive), and b) unnecessary, as calling __del__ will
a
On Sun, Jun 29, 2008 at 9:00 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> As I explained above, it *is* part of a cycle: """including
>> the class objects themselves: class->dict->function->func_globals""".
>
> Ah, right. I must have missed that explanation.
>
>> I know. I assumed Python doe
> Additionally, there is another problem: If the cycle is not
> temporarily revived, and you call __del__ manually, it may break the
> cycle by removing the references.
> Thus, objects in the cycle will go down to refcount=0 during your
> attempt to call __del__'s on the objects in the cycle.
> The
> Firstly, as I said above: you will still have __del__ ordering issues.
Can you please elaborate? What would such __del__ ordering issues be?
> Secondly, the destructor itself currently calls __del__, so if you
> call __del__ before any deallocation, it will get called again as part
> of the dea
> That would be no worse than what happens now - but its still not
> perfect (__del__ ordering issues). Also, you would need to temporarily
> revive the cycles as mentioned above (to avoid accessibility of
> partially destructed objects).
I don't quite understand what you mean by "revive cycles".
> As I explained above, it *is* part of a cycle: """including
> the class objects themselves: class->dict->function->func_globals""".
Ah, right. I must have missed that explanation.
> I know. I assumed Python does not rely on cyclic garbage collectioin
> for shutdown, because it wouldn't work, as
On Sat, Jun 28, 2008 at 10:52 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 28, 2008 at 5:39 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Nick Coghlan wrote:
>>
>>> It's a fact of Python development: __del__ methods cannot safely reference
>>> module globals, because those globals m
Antoine Pitrou pitrou.net> writes:
>
> I was thinking a flag in the PyObject header would do the trick but there
> aren't any flags in the PyObject header... *gasp*.
Actually, we only care about GC-tracked objects (the others are deallocated
simply when their refcount falls to zero), so this cou
eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> Additionally, there is another problem: If the cycle is not
> temporarily revived, and you call __del__ manually, it may break the
> cycle by removing the references.
> Thus, objects in the cycle will go down to refcount=0 during your
> attempt
On Jun 29, 5:12 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> On Jun 29, 3:36 pm, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>
> > eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> > > That would be no worse than what happens now - but its still not
> > > perfect (__del__ ordering issues)
On Jun 29, 3:36 pm, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> eyal.lotem+pyutils gmail.com gmail.com> writes:
>
>
>
> > That would be no worse than what happens now - but its still not
> > perfect (__del__ ordering issues). Also, you would need to temporarily
> > revive the cycles as mentioned
eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> That would be no worse than what happens now - but its still not
> perfect (__del__ ordering issues). Also, you would need to temporarily
> revive the cycles as mentioned above (to avoid accessibility of
> partially destructed objects).
The id
On Jun 29, 3:04 pm, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> eyal.lotem+pyutils gmail.com gmail.com> writes:
>
> > This is exactly what my post tried to address.
> > I assumed it was clear that module clearing is the wrong solution, and
> > that it was also clear that due to the cycles I menti
eyal.lotem+pyutils gmail.com gmail.com> writes:
> This is exactly what my post tried to address.
> I assumed it was clear that module clearing is the wrong solution, and
> that it was also clear that due to the cycles I mentioned
> (global.__class__.__dict__['any_method'].func_globals['global'] i
On Jun 29, 7:52 am, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On Sat, Jun 28, 2008 at 5:39 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Nick Coghlan wrote:
>
> >> It's a fact of Python development: __del__ methods cannot safely reference
> >> module globals, because those globals may be gone
On Jun 28, 6:32 pm, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Example:
>
> > import os
> > class RunningFile(object):
> > filename = '/tmp/running'
> > def __init__(self):
> > open(self.filename, 'wb')
> > def __del__(self):
> > os.unlink(self.filename)
> > runnin
On Jun 28, 6:21 pm, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Eyal Lotem wrote:
> > Example:
>
> > import os
> > class RunningFile(object):
> > filename = '/tmp/running'
> > def __init__(self):
> > open(self.filename, 'wb')
> > def __del__(self):
> > os.unlink(self.filen
On Sat, Jun 28, 2008 at 5:39 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
>> It's a fact of Python development: __del__ methods cannot safely reference
>> module globals, because those globals may be gone by the time that method is
>> invoked.
>
> Speaking of this, has there be
Nick Coghlan wrote:
It's a fact of Python development: __del__ methods cannot safely
reference module globals, because those globals may be gone by the time
that method is invoked.
Speaking of this, has there been any more thought given
to the idea of dropping the module clearing and just
rel
> Example:
>
> import os
> class RunningFile(object):
> filename = '/tmp/running'
> def __init__(self):
> open(self.filename, 'wb')
> def __del__(self):
> os.unlink(self.filename)
> running_file = RunningFile()
>
> The deller object is in a cycle as described above [as
Eyal Lotem wrote:
Example:
import os
class RunningFile(object):
filename = '/tmp/running'
def __init__(self):
open(self.filename, 'wb')
def __del__(self):
os.unlink(self.filename)
running_file = RunningFile()
The deller object is in a cycle as described above [as wel
I see why a cycle that has multiple objects with a __del__ method is a problem.
Once you call __del__ on one of the objects, its no longer usable by
the others, and its not clear which order is correct.
My question regards the case where a cycle of objects only has 1
object which has a __del__.
23 matches
Mail list logo
