On 2007-01-19 22:33, Brett Cannon wrote:
That's a typical error situation you get in __del__ methods at the time the interpreter is shut down.
Yeah, but in this case this is at the end of Py_Initialize() for the stuff I am doing to the interpreter. =)
Is that in some error branch of Py_Initialize() ? Otherwise I don't see how the modules could get garbage-collected.
I'm not exactly sure which global state you are referring to. The aliase map, the cache used by the search function ?
encodings._cache .
Note that the search function registry is a global managed in the thread state (it's not stored in any module).
Right, but that is not the issue. If you have deleted the reference to the encodings module from sys.modules it then sets encodings._cache to None. After the deletion, if you try to encode/decode a unicode string you can an AttributeError about how encodings._cache does not have a 'get' method since it is now None instead of a dict. The function is fine and still runs, it's just that the global state it depends on is no longer the way it assume it should be.
While I could add some tricks to have the cache dictionary stay alive even after the globals were set to None, I doubt that this will really fix the problem. The encoding package relies on the import mechanism, the codecs module and the _codecs builtin module. Any of these could fail to work depending on the order in which the modules get GCed. There's a reason why things in Py_Finalize() are as carefully ordered :-) Perhaps we need to apply some reordering to the steps in Py_Initialize() ?! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 19 2007)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::