Changes by Brett Cannon br...@python.org:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15623
___
___
Python-bugs-list
Brett Cannon added the comment:
So I can't reproduce under 3.2. First off, building the example code in
test.tgz fails thanks to __Py_ZeroStruct not being found (this is with using
both an installed Python 3.2 and a checkout build).
Second, when I just make audioop a package in Python 3.2 it
Stefan Behnel added the comment:
I tried it and it works to just insert the package module into sys.modules
after creation if it's not there yet:
#if PY_MAJOR_VERSION 3
__pyx_m = Py_InitModule4(__Pyx_NAMESTR(my_test_package), __pyx_methods, 0,
0, PYTHON_API_VERSION);
#else
__pyx_m =
Brett Cannon added the comment:
I'm glad the work-around at least works, but I would still like to find out
what the heck 3.2 is doing to see if it's reasonable to replicate in 3.3.
--
___
Python tracker rep...@bugs.python.org
Brett Cannon added the comment:
I had a minute free so I just tried inserting an empty module into sys.modules
and then importing an extension module to see if it would get reused. It
doesn't. imp.load_dynamic() actually just blindly overwrites what is in
sys.modules. I'm willing to bet it
Meador Inge added the comment:
I debugged this a bit by comparing the behavior of 3.3 against 3.2. For both
cases I used the following code and debugged it in Python via pdb*:
import importlib
importlib.__import__('my_test_package')
ISTM that the difference in behavior is a result of
Eric Snow added the comment:
That's helpful, Meador. With regards to the following, there's more to the
story:
With 3.3 a _frozen_importlib.ExtensionFileLoader loader gets created
against 'my_test_package/__init__.so'. This doesn't work because
ExtensionFileLoader does *not* fixup
Brett Cannon added the comment:
So imp.load_dynamic() does add a module to sys.modules (I'm using Python 3.2
here because that's what I have access to, but I verified this yesterday at
home)::
Python 3.2.3 (default, May 3 2012, 15:51:42)
[GCC 4.6.3] on linux2
Type help, copyright, credits
Meador Inge added the comment:
On Mon, Aug 13, 2012 at 12:18 PM, Brett Cannon rep...@bugs.python.org wrote:
So deleting __init__.py and only having __init__.so in Python 3.2 should work.
It doesn't work:
quicksilver:bugs meadori$ python.exe --version
Python 3.2.3+
quicksilver:bugs meadori$
Stefan Behnel added the comment:
Interesting. I didn't know that. The .py file is always installed automatically
next to the .so file by distutils.
Here's what strace gives me:
Python 2.7:
stat(my_test_package, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
stat(my_test_package/__init__.py,
Brett Cannon added the comment:
My guess is import.c is noticing the __init__.py, creating the module for the
package, and then somehow it cascades into importing __init__.so which
essentially does a reload on the module object that is already in sys.modules
and thus doesn't cause the parent
Eric Snow added the comment:
I was able to reproduce the error using a fresh build from tip (34d5ec8a1019):
/tmp/test$ PYTHON=/opt/python3.3/bin/python3 ./test.sh
['__main__', '_bisect', '_codecs', '_collections', '_frozen_importlib',
'_functools', '_heapq', '_imp', '_io', '_locale', '_sre',
Eric Snow added the comment:
The files, post-run:
$ find /tmp/test/
/tmp/test/
/tmp/test/my_test_package
/tmp/test/my_test_package/__init__.cpython-33dm.so
/tmp/test/my_test_package/a.cpython-33dm.so
/tmp/test/my_test_package/a.c
/tmp/test/my_test_package/a.py
Eric Snow added the comment:
Traceback when run verbosely:
Traceback (most recent call last):
File string, line 1, in module
File frozen importlib._bootstrap, line 1529, in _find_and_load
File frozen importlib._bootstrap, line 1496, in _find_and_load_unlocked
File frozen
Eric Snow added the comment:
in ___init__.c:963+, prior to executing the module proper (Python2 and PyPy
handling removed):
/*--- Module creation code ---*/
__pyx_m = PyModule_Create(__pyx_moduledef);
if (!__pyx_m) {...};
__pyx_b =
Stefan Behnel added the comment:
That's the module init code, yes, including the setting of __file__ and
__path__ that I mentioned (due to issue13429). Setting at least one of the two
is required in previous CPython versions to make relative imports work.
--
Changes by Georg Brandl ge...@python.org:
--
priority: normal - deferred blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15623
___
___
Brett Cannon added the comment:
I don't have time to delve into C debugging right now, but the question is what
changed between 3.2 and 3.3 in terms of when an extension module is inserted
into sys.modules since that is the issue ATM. Probably some time in gdb
starting in the module's init
Eric Snow added the comment:
This smells like a case of where sys.modules got replaced by another mapping,
but import.c continues using interp-modules. I won't be able to investigate
until tomorrow.
--
___
Python tracker rep...@bugs.python.org
Changes by Georg Brandl ge...@python.org:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15623
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15623
___
___
Python-bugs-list
New submission from Stefan Behnel:
Since CPython 2.5, relative imports could be used from __init__.so package
modules. This stopped working in CPython 3.3.
This is a follow-up ticket to issue15576.
This feature is exercised by Cython's initial_file_path test, which now gives
this result:
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15623
___
Brett Cannon added the comment:
The trigger of that exception is importlib._bootstrap._sanity_check()
(http://hg.python.org/cpython/file/5e025dc7d728/Lib/importlib/_bootstrap.py#l1466).
It's called very early on to verify certain things, including that the parent
package is already loaded
Stefan Behnel added the comment:
We are continuously testing Cython against all CPython versions starting from
2.4, so I can assure you that it's still working for all other versions. Here's
our CI server:
https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/618/
I just tried
25 matches
Mail list logo
