Author pitrou
Recipients pitrou, vstinner
Date 2010-08-09.19:09:28
SpamBayes Score 3.36388e-10
Marked as misclassified No
Message-id <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-08-09 19:09:31pitrousetrecipients: + pitrou, vstinner
2010-08-09 19:09:31pitrousetmessageid: <1281380971.62.0.695264636628.issue9548@psf.upfronthosting.co.za>
2010-08-09 19:09:29pitroulinkissue9548 messages
2010-08-09 19:09:28pitroucreate