➜
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.
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) *  |
Date: 2008-12-01 05:06 | |
I can't reproduce that: /tmp/h$ echo "pass" > x.py /tmp/h$ mkdir types :/tmp/h$ /tmp/py3/bin/python3.0 -mcompileall . Listing . ... Listing ./types ... Compiling ./x.py ... /tmp/h$ ls types x.py x.pyc |
|||
| msg76678 - (view) | Author: Michael Aivazis (aivazis) | Date: 2008-12-01 05:12 | |
sorry for the sloppy report. add a __init__.py in the types subdir. you should get a "Could not import runpy module" error. |
|||
| msg121512 - (view) | Author: Éric Araujo (eric.araujo) * |
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) * |
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) * |
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) * |
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) * |
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) * |
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 |
|||
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:41 | admin | set | github: 48726 |
| 2021-07-31 15:03:05 | fbidu | set | pull_requests: - pull_request26023 |
| 2021-07-31 15:02:49 | fbidu | set | messages: + msg398643 |
| 2021-07-31 13:07:56 | fbidu | set | nosy:
+ fbidu pull_requests: + pull_request26023 |
| 2010-11-19 16:00:53 | eric.araujo | set | messages: + msg121544 |
| 2010-11-19 15:50:58 | ncoghlan | set | messages: + msg121543 |
| 2010-11-19 15:32:29 | eric.araujo | set | messages: + msg121538 |
| 2010-11-19 15:27:14 | ncoghlan | set | status: open -> closed resolution: not a bug messages: + msg121535 stage: needs patch -> resolved |
| 2010-11-19 13:38:09 | eric.araujo | set | nosy:
+ brett.cannon, ncoghlan messages: + msg121513 |
| 2010-11-19 13:32:28 | eric.araujo | set | title: compileall.py 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:34 | eric.araujo | set | nosy:
+ eric.araujo versions: + Python 3.1, Python 3.2, - Python 3.0 |
| 2008-12-01 05:12:25 | aivazis | set | messages: + msg76678 |
| 2008-12-01 05:06:13 | loewis | set | nosy:
+ loewis messages: + msg76676 |
| 2008-12-01 00:32:52 | aivazis | create | |