Antoine Pitrou 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__:
tarfile: looks not
On Wed, Oct 14, 2009 at 6:05 PM, Neil Schemenauer 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 executed and the
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 wor
On Wed, Oct 14, 2009 at 4:42 PM, Neil Schemenauer 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__ methods is okay.
>
On Wed, Oct 14, 2009 at 2:45 PM, Neil Schemenauer 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 would be
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
pl
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 3:16 PM, Neil Schemenauer 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.
>
>
Neil Schemenauer 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
cu
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 h
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
seems
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.
-Ba
> 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
http://mail.python.org/mailma
13 matches
Mail list logo
