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.

Title: compileall fails if current dir has a "types" package
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.1, Python 3.2
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: aivazis, brett.cannon, eric.araujo, fbidu, loewis, ncoghlan
Priority: normal Keywords:

Created on 2008-12-01 00:32 by aivazis, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (9)
msg76676 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-01 05:06
I can't reproduce that:

/tmp/h$ echo "pass" >
/tmp/h$ mkdir types
:/tmp/h$ /tmp/py3/bin/python3.0 -mcompileall .
Listing . ...
Listing ./types ...
Compiling ./ ...
/tmp/h$ ls
types  x.pyc
msg76678 - (view) Author: Michael Aivazis (aivazis) Date: 2008-12-01 05:12
sorry for the sloppy report. add a in the types subdir. you 
should get a "Could not import runpy module" error.
msg121512 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-19 13:32
I can reproduce in 3.1 and 3.2.  2.7 is okay.
msg121513 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-19 13:38
python -v shows that runpy tries to import pkgutil which imports types which is the package in the current directory.  Is this an import bug or a worksforme “don’t use standard module names in your projects”?
msg121535 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-11-19 15:27
Indeed, any time you shadow a standard library module you run the risk of breaking things. runpy (and its dependencies) are just like any other module in that respect.
msg121538 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-19 15:32
Do you think it would be useful to update the doc of compileall?
msg121543 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2010-11-19 15:50
No. Once you start shadowing standard library modules, all bets are off as to what will and won't work. It's one of the reasons we need to be somewhat careful with the naming of new standard library modules.

I'm mildly curious as to why 2.7 didn't also throw ImportError*, but given the description, I don't consider it incorrect behaviour that this scenario broke in 3.x.

*Off the top of my head, I would guess it is due to the change in initialisation order needed to bootstrap the new IO stack in 3.x, but it would take a bit of investigation to confirm that
msg121544 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-11-19 16:00
Thanks for the replies.
msg398643 - (view) Author: Felipe Rodrigues (fbidu) * Date: 2021-07-31 15:02
sorry about the noise, everyone. Missed an '6' in the end of the issue name
Date User Action Args
2022-04-11 14:56:41adminsetgithub: 48726
2021-07-31 15:03:05fbidusetpull_requests: - pull_request26023
2021-07-31 15:02:49fbidusetmessages: + msg398643
2021-07-31 13:07:56fbidusetnosy: + fbidu

pull_requests: + pull_request26023
2010-11-19 16:00:53eric.araujosetmessages: + msg121544
2010-11-19 15:50:58ncoghlansetmessages: + msg121543
2010-11-19 15:32:29eric.araujosetmessages: + msg121538
2010-11-19 15:27:14ncoghlansetstatus: open -> closed
resolution: not a bug
messages: + msg121535

stage: needs patch -> resolved
2010-11-19 13:38:09eric.araujosetnosy: + brett.cannon, ncoghlan
messages: + msg121513
2010-11-19 13:32:28eric.araujosettitle: fails if current dir has a "types" subdir with 3.0 (ok with 2.5) -> compileall fails if current dir has a "types" package
messages: + msg121512
stage: needs patch
2010-11-18 16:04:34eric.araujosetnosy: + eric.araujo

versions: + Python 3.1, Python 3.2, - Python 3.0
2008-12-01 05:12:25aivazissetmessages: + msg76678
2008-12-01 05:06:13loewissetnosy: + loewis
messages: + msg76676
2008-12-01 00:32:52aivaziscreate