[I initially posted this email to python-list but didn't get any reply,
probably because this is too related to python core, so I'm posting it
again here, hope that's ok...]
I'm currently working on implementing Import Hooks (PEP302) with Python
2.7 to be able to import modules whose code is in ZODB. However, I have
stumbled upon a widely known issue about import deadlock (note
that this issue is not directly related to ZODB, but a more general
question about dealing with import lock deadlock for Import Hooks),
Thread 1 is trying to import a module 'foo.bar' (where 'foo' is a
package containing dynamic modules) handled by Import Hooks I
implemented, so import lock is acquired before even running the hooks
(Python/import.c:PyImport_ImportModuleLevel()). Then, these import
hooks try to load objects from ZODB and a request is sent and handled
by another thread (Thread 2) which itself tries to import another
module. Of course, this causes a deadlock because the first thread
still holds import lock.
I have thought about the following solutions:
* Backport the patch applied in python 3.3 from issue 9260. This
would be the best option because it would mean that even when trying
to import any module from package 'foo', other modules and packages
can be imported, which would solve my issue. However, I'm not sure it
could be released into python 2.7?
* Within the hooks, protect the Import Hooks with a separate lock for
the loader method. This would prevent any other thread to import any
modules from 'foo' package but still allows to call the finder method
(ignoring module fullname not starting with 'foo') along with other
finder methods, so that other ZODB modules can be imported.
Then, in the loader method, until the module is actually inserted into
sys.modules and then other load_module() PEP302 responsabilities being
taken care of (such as exec the code), release the import lock so that
Thread 2 can process requests and send objects back to Thread 1.
About the finder method, I think that the separate lock is enough and
releasing the import lock until the end of the method should be
However, even after trying to understand import.c, I'm not sure this
is enough and that releasing import lock would not have nasty
side-effects, any thoughts about that?
* Fix the ZODB code to not avoid import but to me this seems like a
dirty hack because it could happen again and I would prefer to fix
this issue once and for all.
Any thoughts or suggestion welcome, thanks!
I have written a revised version of PEP 247. It's heavily based on AMKs
original version from 2001. Version 2.0 adds ``name`` and ``block_size``
as mandatory attributes. It defines that hashing objects operate only on
byte-like objects in Python 3.x, too.
I have also developed an abstract base class for cryptographic hashing
algorithm . Should I add it to the PEP and make it mandatory for
Related to the current deprecation discussion:
This is a master list of deprecated items scheduled for removal in 3.4.
Anything that is going to be removed should be done now, before the next
Terry Jan Reedy
I have raise a tracker item and PEP for adding a statistics module to the standard library:
and I'm about to submit a patch containing my updated code and tests, but I've run into a problem with testing. My existing tests use unittest, and follow the basic boilerplate documented here:
and when run directly they pass, but when I try to run them using Python 3.4a -m test -j3 they break. My question is, is it acceptable to post the code and tests to the tracker as-is, and ask for a pronouncement on the PEP first, and then fix the test breakage later? If not, can somebody mentor me in understanding what I need to do here?
To avoid all doubt, the tests pass if I call them like this:
but raise errors when I call them like this:
./python -m test -j3
Thanks in advance,
It seems NULL is allowed as the first argument of PyErr_Format,
PyErr_SetString and PyErr_SetObject. Moreover, it means "clear the
error indicator". However, this is not mentioned in the docs. I was
wondering if we should officialize this behaviour or change it.