New submission from Antoine Pitrou <pit...@free.fr>: 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. ---------- components: Library (Lib) messages: 113457 nosy: haypo, pitrou priority: normal severity: normal status: open title: locale can be imported at startup but relies on too many library modules type: behavior versions: Python 3.2 _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9548> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com