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 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 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
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, 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:
>
> 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: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
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)
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
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
On Sun, Jun 29, 2008 at 12:59 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Looks about equivalent, but "survivors" may mean two different things
>> depending on if it removes deleted survivors or not. Splitting that
>> up, we get this form:
>>
>> old <= survivors * 2.0 + deleted * 1.0
>
> W
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
>> What precisely would be the "deleted" count? If it counts deallocations,
>> is it relevant what generation the deallocated object was from?
>> If so, how do you determine the generation? If not, wouldn't
>>
>> while 1:
>> x=[]
>>
>> trigger a full garbage collection fairly quickly?
>
> "delet
> 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
> 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".
> 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
> 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
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
On Sun, Jun 29, 2008 at 11:49 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
>>> What precisely would be the "deleted" count? If it counts deallocations,
>>> is it relevant what generation the deallocated object was from?
>>> If so, how do you determine the generation? If not, wouldn't
>>>
>>>
> 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 12:46 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Is everyone agreed on a tohex/fromhex pair using the C99 notation as
> recommended in 754R?
Sounds good to me.
I've attached a Python version of a possible implementation to the issue. See:
http://bugs.python.org/fi
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
22 matches
Mail list logo
