This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients pitrou, vstinner
Date 2010-08-09.19:09:28
SpamBayes Score 3.36388e-10
Marked as misclassified No
Message-id <>
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/
- Lib/ 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 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/ when initializing std{in,out,err} brings too many import dependencies.

A possible solution is to define a subset of that is used for bootstrap and rely on as little modules as possible.
Date User Action Args
2010-08-09 19:09:31pitrousetrecipients: + pitrou, vstinner
2010-08-09 19:09:31pitrousetmessageid: <>
2010-08-09 19:09:29pitroulinkissue9548 messages
2010-08-09 19:09:28pitroucreate