Davin Potts added the comment:
Having installed a fresh copy of Debian Hurd into a VM, I am able to reproduce
the described issue using this 2-line snippet of code:
import multiprocessing
q = multiprocessing.Queue()
It was possible to reproduce the issue both using the builds of 2.7.9 and 3.4.2
that came with Debian Hurd and with clean builds of each from the Python source
code for those releases.
Although already described in the original issue report, I'm taking the
venerable astropy package out of the picture with this bare-bones provocation
of the issue here. So running the above code snippet with 2.7.9 produces an
ImportError and with 3.4.2 produces an AttributeError (details of error message
are as previously described).
I agree that the behavior should be consistent between 2.7 and 3.x -- I'm
leaning towards the consistent use of ImportError because that is what's used
when threading support isn't available on a platform (i.e. 'import thread' or
'import threading' fails with an ImportError there).
As to where this should be documented in the documentation itself so that
readers have a hope of finding it... that requires a bit more thought but I
agree that it should be noted in the documentation. Thinking in pragmatic
terms, most folks will probably not read the docs and instead notice it at the
time of the failing import so the error message should be clear and consistent
there.
It does not look like there is a working implementation of sem_open() on Debian
Hurd yet -- is that correct? Otherwise there's another more attractive
potential fix for this.
----------
nosy: +davin
stage: -> needs patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue23400>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
