That seems to argue for doing rc2 on Sunday the 18th. If I tag the
release some time Saturday, you could have the binaries by Sunday
right?
Correct.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Oct 14, 2009, at 8:06 AM, Martin v. Löwis wrote:
That seems to argue for doing rc2 on Sunday the 18th. If I tag the
release some time Saturday, you could have the binaries by Sunday
right?
Correct.
Cool. I've updated the Python Release Schedule calendar to reflect
the new dates.
The current shutdown code in pythonrun.c zaps module globals by
setting them to None (an attempt to break reference cycles). That
causes problems since __del__ methods can try to use the globals
after they have been set to None.
The procedure implemented by http://bugs.python.org/issue812369
On 08:16 pm, n...@arctrix.com wrote:
The current shutdown code in pythonrun.c zaps module globals by
setting them to None (an attempt to break reference cycles). That
causes problems since __del__ methods can try to use the globals
after they have been set to None.
The procedure implemented by
Neil Schemenauer nas at arctrix.com writes:
I would like to commit this change but I'm not sure if it is a good
time in the development cycle or if anyone has objections to the
idea. Please speak up if you have input.
Have you tried to remove the various hacks/workarounds in the stdlib that
On Wed, Oct 14, 2009 at 3:16 PM, Neil Schemenauer n...@arctrix.com wrote:
The current shutdown code in pythonrun.c zaps module globals by
setting them to None (an attempt to break reference cycles). That
causes problems since __del__ methods can try to use the globals
after they have been set
On Wed, Oct 14, 2009 at 04:13:12PM -0500, Daniel Stutzbach wrote:
Based on the description, it still resorts to zapping module globals by
setting them to None. It zaps them to weakrefs first, which means that
globals are more likely to be valid during __del__, but it still cannot make
any
On Wed, Oct 14, 2009 at 08:35:28PM -, exar...@twistedmatrix.com wrote:
I notice that the patch doesn't include any unit tests for the feature
being provided
That's hard to do although I suppose not impossible. We would be
trying to test the interpreter shutdown procedure. I suppose on
On Wed, Oct 14, 2009 at 2:45 PM, Neil Schemenauer n...@arctrix.com wrote:
On Wed, Oct 14, 2009 at 08:35:28PM -, exar...@twistedmatrix.com wrote:
I notice that the patch doesn't include any unit tests for the feature
being provided
That's hard to do although I suppose not impossible. We
On Wed, Oct 14, 2009 at 4:42 PM, Neil Schemenauer n...@arctrix.com wrote:
Yes, it does still resort to setting globals to None. However, the
weakref step makes it much more likely that __del__ methods run
before that happens. After this change, referencing global variables
from __del__
On Wed, Oct 14, 2009 at 05:35:38PM -0500, Daniel Stutzbach wrote:
The first and last sentences seem like a contradiction to me. If I cannot
guarantee that globals will be valid when __del__ is executed, then I must
not reference globals from __del__.
I think there is confusion about the word
On Wed, Oct 14, 2009 at 6:05 PM, Neil Schemenauer n...@arctrix.com wrote:
def __del__():
print sys.version
the global variable reference to 'sys' is not a reference on the GC
referencing counting sense. IOW, it does not result in a a Py_INCREF
while the function is not being
Antoine Pitrou solip...@pitrou.net wrote:
Have you tried to remove the various hacks/workarounds in the
stdlib that currently avoid module finalization problems?
Good idea. These hacks are the best argument for applying the
change, IMHO. I made a quick review of Lib modules using __del__:
13 matches
Mail list logo
