Message113457
Consider the two following commands, from an SVN working copy:
$ ./python -c 'import heapq; print(heapq.heapify)'
<built-in function heapify>
$ cat | ./python -c 'import heapq; print(heapq.heapify)'
<function heapify at 0x7f5d456025a0>
In the second case, the "from _heapq import *" in heapq fails silently. The reason was a bit difficult to find, but it goes as following:
- when run from a non-pty, initializing the standard streams imports Lib/locale.py
- Lib/locale.py import collections which import heapq
- heapq tries to import _heapq but, at this point, the build dir (such as "build/lib.linux-x86_64-3.2/") hasn't been added to sys.path, since site.py does it: the import fails
- heapq silences the ImportError, and this early loaded copy of the module is then made available to all subsequent consumers of heapq, without C accelerators
The issue might seem rather exotic, but it is a more general symptom of the problem that importing Lib/locale.py when initializing std{in,out,err} brings too many import dependencies.
A possible solution is to define a subset of locale.py that is used for bootstrap and rely on as little modules as possible. |
|
Date |
User |
Action |
Args |
2010-08-09 19:09:31 | pitrou | set | recipients:
+ pitrou, vstinner |
2010-08-09 19:09:31 | pitrou | set | messageid: <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za> |
2010-08-09 19:09:29 | pitrou | link | issue9548 messages |
2010-08-09 19:09:28 | pitrou | create | |
|