[issue26160] [doc] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

Change by Irit Katriel : -- title: Tutorial incorrectly claims that (explicit) relative imports don't work in the main module -> [doc] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module versions: +Python 3.10, Python 3.11, Python 3.9 -Pyt

[issue19510] lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line

Change by Irit Katriel : -- resolution: -> wont fix stage: -> resolved status: open -> closed superseder: -> Close 2to3 issues and list them here ___ Python tracker ___

[issue43005] Package Relative Imports - double dot doc example not working

Guido van Rossum added the comment: This is not a bug in Python. Please ask a user forum for help understanding (for example, https://discuss.python.org/c/users/7). -- nosy: +gvanrossum resolution: -> not a bug stage: -> resolved status: open -> closed

[issue43005] Package Relative Imports - double dot doc example not working

-relative-imports The following instructions mimic pretty well the doc example : ```bash mkdir package cd package touch __init__.py mkdir subpackage1 touch subpackage1/__init__.py mkdir subpackage2 touch subpackage2/__init__.py echo "eggs = 42" > subpackage2/moduleZ.py echo "from ..s

[issue41616] Global variable in whole project and Relative imports problem

Change by Guido van Rossum : -- stage: -> resolved status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41616] Global variable in whole project and Relative imports problem

comments about relative imports don't seem to be either a feature request or a bug report, but just a vague complaint that it often causes problems. Please be more precise. Problems with global variables are nearly always problems with global variables, not bugs with Python. Global variables

[issue41616] Global variable in whole project and Relative imports problem

many often calling module in main to operate with, where this way made many problems withs Relative imports https://stackoverflow.com/questions/30669474/beyond-top-level-package-error-in-relative-import https://stackoverflow.com/questions/14132789/relative-imports-in-python-2-7/ https

How does the import machinery handle relative imports?

I'm fussing over some details of relative imports while trying to mimic Python module loading in my personal project. This is getting more into corner cases, but I can spare time to talk about it while working on more normal stuff. I first found this place: https://manikos.github.io/how-pythons

[issue19510] lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line

Batuhan added the comment: > It’s still a bug though :) It gives a warning about this though RefactoringTool: ### In file test/t.py ### RefactoringTool: Line 1: absolute and local imports together If it still counts as a bug, let me know and i'll try to prepare a patch. --

[issue38509] Insufficient description of relative imports in docs.python.org

New submission from Aniruddha Bhattacharjee : In the section "relative imports" of the documentation for "import system", the use of relative imports is explained with the use of an example, however if you try the exact same thing it gives an error. This is nicely

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Change by Nick Coghlan : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: behavior -> enhancement versions: +Python 3.8 -Python 3.5, Python 3.6 ___ Python tracker

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Nick Coghlan added the comment: New changeset 4d0233ec656bc7e7814e5f6f484e79a50a0daf91 by Nick Coghlan (Miss Islington (bot)) in branch '3.7': bpo-30840: Document relative imports (GH-12831) (GH-12938) https://github.com/python/cpython/commit/4d0233ec656bc7e7814e5f6f484e79a50a0daf91

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Nick Coghlan added the comment: New changeset 70bf713617e15fad390ed953e48b3c65d9bc90ec by Nick Coghlan (Joannah Nanjekye) in branch 'master': bpo-30840: Document relative imports (#12831) https://github.com/python/cpython/commit/70bf713617e15fad390ed953e48b3c65d9bc90ec

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Change by miss-islington : -- pull_requests: +12862 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Joannah Nanjekye added the comment: Great, thanks for clarity. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Brett Cannon added the comment: RE: "does it mean we dont need this to work anymore as was earlier put in the PEP?" Correct, we aren't going to implement that part of the PEP ever. -- ___ Python tracker

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Joannah Nanjekye added the comment: I actually opened a PR with the relevant documentation suggested by @ncoghlan but what am wondering is. when @ncoghlan says That part of the PEP was never implemented - relative imports have never been allowed to cross package boundaries in practice

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Change by Joannah Nanjekye : -- keywords: +patch pull_requests: +12756 stage: -> patch review ___ Python tracker ___ ___

[issue35556] See if frozen modules can use relative imports

if frozen modules can use relative imports type: behavior ___ Python tracker <https://bugs.python.org/issue35556> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33547] Relative imports do not replace local variables

Nick Coghlan added the comment: Not as a statement, but you can force it with importlib.import_module: $ python3 -c "import pkg; pkg.submodule = 1; import importlib; importlib.import_module('.submodule', 'pkg'); print(pkg.submodule)" pkg pkg.submodule We're getting

[issue33547] Relative imports do not replace local variables

Rolf Campbell <thats.unpossi...@gmail.com> added the comment: Is there any way to use relative imports and explicitly request a sub-module? >From PEP 328: "import <> is always absolute" So it sounds like there is no way to duplicate the explicit request for a sub-m

[issue33547] Relative imports do not replace local variables

Nick Coghlan <ncogh...@gmail.com> added the comment: Yes, while weird, that's expected behaviour. Rather than being due to absolute vs relative imports, the difference arises from the fact that in "import pkg.module", the request is explicitly for a submodule, so the submodu

[issue33547] Relative imports do not replace local variables

Rolf Campbell added the comment: OK, while I understand what you are saying, that is NOT how absolute imports work. I'll give an example: ./main.py:import func ./main.py:print(f"Value of func.func after import func:{func.func}") ./main.py:import func.func

[issue33547] Relative imports do not replace local variables

R. David Murray added the comment: Yes, you are substantially correct. A subtlety that may enhance your understanding (if it doesn't instead totally confuse you :) is that __init__ is simply the most straightforward way to affect the module namespace. You would see

[issue33547] Relative imports do not replace local variables

Rolf Campbell added the comment: OK, OK, I think I finally understand what you mean here. Let me try to repeat it just to make sure I really understand: When requesting a member of a multi-file module (like "func" in my example), python only tries to load that

[issue33547] Relative imports do not replace local variables

R. David Murray added the comment: It's the same answer. __init__ *is* the package namespace, so you are setting the value of 'func' in the package (.) namespace, and what import is doing is correct. I know this is confusing. I banged my head against it while

[issue33547] Relative imports do not replace local variables

Change by Rolf Campbell : -- resolution: not a bug -> ___ Python tracker ___

[issue33547] Relative imports do not replace local variables

Rolf Campbell added the comment: Re-opening because I've found a simple example that does not involve __main__. ./func/__init__.py:func = 1 ./func/__init__.py:from . import func ./func/__init__.py:print(f"Namespace value of func after func module import:{func}")

[issue33547] Relative imports do not replace local variables

Rolf Campbell added the comment: Thanks David, I agree that my assumption that the local valiables were not being replaced is not really what was going on there. I also agree that, while this might not strictly classify as a bug, it's probably not the most

[issue33547] Relative imports do not replace local variables

Nick Coghlan added the comment: As David notes, the issue in the example is the fact that you're setting "__main__.a", so "a.py" never gets imported as a module - it gets a hit on the parent module attribute, and hence stops there. -- resolution: -> not a bug

[issue33547] Relative imports do not replace local variables

R. David Murray added the comment: It's importing 'a' from '.', which I guess in this context means from the current namespace (__main__), and a is 7. You'll note that 'b' did get repointed, but it got repointed to what 'a' points to, instead of to 5. If it really

[issue33547] Relative imports do not replace local variables

Rolf Campbell added the comment: Under simple circumstances, this is only reproducible when either directly in an interactive Python session (or as -c), but I encountered this type of problem in a much more complicated project which was NOT running as part of an

[issue33547] Relative imports do not replace local variables

New submission from Rolf Campbell <thats.unpossi...@gmail.com>: Relative imports do not replace local variables, but also don't fail. This can cause some very strange outcomes like this simple example: touch a.py; python3.6 -c 'a=7; b=5; from . import a as b; print(a,b)' I would

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Nick Coghlan added the comment: That part of the PEP was never implemented - relative imports have never been allowed to cross package boundaries in practice (which is also why "from . import sys" doesn't work as an equivalent to "import sys" at the interactive prompt or i

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

Changes by R. David Murray : -- assignee: -> docs@python components: +Documentation nosy: +brett.cannon, docs@python, eric.snow, ncoghlan versions: +Python 3.6, Python 3.7 ___ Python tracker

[issue30840] Contrary to documentation, relative imports cannot pass through the top level

New submission from Malcolm Smith: https://docs.python.org/3/reference/simple_stmts.html#the-import-statement defers the full specification of relative imports to PEP 328. PEP 328 gives the example "from ...sys import path" in a second-level package, and notes "while that las

[issue29929] Eliminate implicit __main__ relative imports

Ronald Oussoren added the comment: If only someone had access to the time machine keys to fix this 20 year ago :-(. Anything beyond that last option (recognising that the script tries to import itself under another name) is bound to run into odd issues or backward compatibility concerns.

[issue29929] Eliminate implicit __main__ relative imports

Nick Coghlan added the comment: Ronald: that depends somewhat on how the installation is handled. For example, for entrypoints-style scripts, the entirety of __main__ is auto-generated anyway, and anyone using "./setup.py develop" or "pip install -e ." to add a suitable sys.path entry during

[issue29929] Eliminate implicit __main__ relative imports

Ronald Oussoren added the comment: A disadvantage of requiring "from . import ..." to import modules next to the script is that this requires a different mechanism before and after installation of a script. That is, before installation the additional modules are next to the script ("from .

[issue29929] Eliminate implicit __main__ relative imports

Changes by Chris Angelico : -- nosy: +Rosuav ___ Python tracker ___ ___ Python-bugs-list

[issue29929] Eliminate implicit __main__ relative imports

Nick Coghlan added the comment: See https://mail.python.org/pipermail/import-sig/2017-March/001068.html for the above-mentioned import-sig post (the design in that email isn't the same as the one described above, but later in the thread I decided the design suggested here is likely to be less

[issue29929] Eliminate implicit __main__ relative imports

Changes by Barry A. Warsaw : -- nosy: +barry ___ Python tracker ___ ___ Python-bugs-list

[issue29929] Eliminate implicit __main__ relative imports

Nick Coghlan added the comment: In formulating a post to import-sig about this, I realised it made more sense to describe it in terms of the goal (eliminating implicit __main__ relative imports) rather than one possible technique for achieving that goal. -- title: Idea: Make __main__

Re: Python programs and relative imports

On Fri, Apr 8, 2016 at 11:50 AM, Rob Gaddi wrote: > Sort of. If I've got a directory full of files (in a package) > that I'm working on, the relative import semantics change based on > whether I'm one directory up and importing the package or in the same >

Re: Python programs and relative imports

On Sat, Apr 9, 2016 at 3:50 AM, Rob Gaddi wrote: > Sort of. If I've got a directory full of files (in a package) > that I'm working on, the relative import semantics change based on > whether I'm one directory up and importing the package or in the same >

Re: Python programs and relative imports

Chris Angelico wrote: > On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi > <rgaddi@highlandtechnology.invalid> wrote: >> Rob Gaddi wrote: >> >>> Does anyone know the history of why relative imports are only available >>> for packages and not for

Re: Python programs and relative imports

On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi <rgaddi@highlandtechnology.invalid> wrote: > Rob Gaddi wrote: > >> Does anyone know the history of why relative imports are only available >> for packages and not for "programs"? It certainly complicates life. >

Re: Python programs and relative imports

Rob Gaddi wrote: > Does anyone know the history of why relative imports are only available > for packages and not for "programs"? It certainly complicates life. > Really, no one? It seems like a fairly obvious thing to have included; all of the reasons that you want to be

Python programs and relative imports

Does anyone know the history of why relative imports are only available for packages and not for "programs"? It certainly complicates life. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.

[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___

[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

o import in that case. I simply replaced "__package__" with "the name of the current package" to make it easier to read, much as the original text replaces "__name__" with "the name of the current module." >Then point out that relative imports won’

[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

relative imports are based on the _full_ name of the current module. It could be misleading saying “the name of the current package”, because the import could be relative to the a higher level parent package if more than one dot is specified. Then point out that relative imports won’t work

[issue26160] Tutorial incorrectly claims that (explicit) relative imports don't work in the main module

New submission from Kevin Norris: The tutorial contains this statement: Note that relative imports are based on the name of the current module. Since the name of the main module is always "__main__", modules intended for use as the main module of a Python application must always us

[issue25294] Absolute imports fail in some cases where relative imports would work

ay the related name binding (and name lookup in 3.5+) works, not between absolute and relative imports. The relevant terminology to distinguish between "from ... import ..." vs "import ..." is just "from import" vs "non-from import", and there are definitely cases

[issue25294] Absolute imports fail in some cases where relative imports would work

Nick Coghlan added the comment: (Oops, it seems Brett already clarified the terminology. My apologies for the noise). Modularity and module design is hard. It's one of the hardest problems in software engineering, which is why folks invent entire new vocabularies to attempt to describe the

[issue25294] Absolute imports fail in some cases where relative imports would work

Brett Cannon added the comment: You have to realize, Patrick, that the ability for `from ... import ...` to work in some situations that `import ...` won't is an age-old problem -- they are different at the bytecode level as well as how __import__ handles them -- and starting in Python 3.5 it

[issue25294] Absolute imports fail in some cases where relative imports would work

Patrick Maupin added the comment: You are correct that I have conflated two issues, but they are not orthogonal -- if you choose to use relative imports, you will never encounter this issue, because your imports will all be of the 'from ... import' form. (And, as you point out, the fact

[issue25294] Absolute imports fail in some cases where relative imports would work

Patrick Maupin added the comment: concurrent/futures/__init__.py may be a better example than 2to3 for this issue. It's relatively new code, it's part of the standard library, it's fairly small and self-contained, and it doesn't follow the promulgated standard. If it's bad code, it should be

[issue25294] Absolute imports fail in some cases where relative imports would work

Patrick Maupin added the comment: I don't think anything is wrong with that code. But PEP 8 prescribes a way of doing something that often won't work (which is unusual for PEP 8), with no discussion of this fact. > I think the key thing to take away from this whole discussion is "don't have

[issue25294] Absolute imports fail in some cases where relative imports would work

Brett Cannon added the comment: I don't quite follow what you think is wrong with https://hg.python.org/cpython/file/tip/Lib/concurrent/futures/__init__.py . It looks totally fine to me. And I should mention that you shouldn't follow PEP 8 like it's in stone and the only way to format code.

[issue25294] Absolute imports fail in some cases where relative imports would work

Nick Coghlan added the comment: Issue 992389 is the previous incarnation of this bug report, while issue 17636 made the change so that from imports will resolve in some situations where this error will occur. That fact that "from x.y.b import foo" may now resolve in cases where "import

[issue25294] Absolute imports fail in some cases where relative imports would work

w he finds that there are two ways to make it work: (1) Use the disparaged relative imports; or (2) flatten his package to a single level, because importing X.Z from within X.Y will work fine. IMO, the language that Nick proposes for PEP 8 will either (a) not be understood at all by the frustra

[issue25294] Absolute imports fail in some cases where relative imports would work

Nick Coghlan added the comment: If that's the concern, then the relevant guidance is to avoid running code at package import time (which many new developers will now do by default with __init__.py becoming optional). -- ___ Python tracker

[issue25294] Absolute imports fail in some cases where relative imports would work

a question on Stack Overflow. My initial response was "well, duh, obviously relative imports are more Pythonic here because that's the obvious way to do it (that works)." But then, of course, PEP 8 disagrees. For that actual question on Stack Overflow, you would have to carefully define

[issue25294] Absolute imports fail in some cases where relative imports would work

Changes by Berker Peksag : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker ___

[issue25294] Absolute imports fail in some cases where relative imports would work

Changes by J Richard Snape : -- nosy: +J Richard Snape ___ Python tracker ___ ___

[issue23447] Relative imports with __all__ attribute

Steven Barker added the comment: This issue is a special case of the problem discussed in issue 992389, that modules within packages are not added to the package dictionary until they are fully loaded, which breaks circular imports in the form from package import module. The consensus on

[issue23447] Relative imports with __all__ attribute

Brett Cannon added the comment: If you put a print call after your `from . import *` call you will notice it never gets executed. Basically import is still in the middle of finishing imports when that import * is reached, including setting the module attributes on the package. Basically you

[issue23447] Relative imports with __all__ attribute

Antonio Cota added the comment: I tried the following on python 3.5.0a1: #init.py __all__ = ['second', 'first'] print('i\'m starting the directory') #first.py print('hi, i\'m the first') from . import second #second.py print('hi, i\'m the second') from . import first import a.first i'm

[issue23447] Relative imports with __all__ attribute

Changes by Antonio Cota antocot...@gmail.com: -- versions: -Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23447 ___ ___

[issue23447] Relative imports with __all__ attribute

. -- messages: 235761 nosy: antox priority: normal severity: normal status: open title: Relative imports with __all__ attribute type: behavior versions: Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23447

[issue23447] Relative imports with __all__ attribute

Changes by Antonio Cota antocot...@gmail.com: -- versions: +Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23447 ___ ___

Re: Incompatible idioms: relative imports, top-level program file

On Sunday, February 8, 2015 at 3:52:19 AM UTC+5:30, Gregory Ewing wrote: Rustom Mody wrote: Wanted to try out sympy. apt-install promised ź GB download, ž GB space usage Just getting a src-tarball was: 6M download, 30M after opening the tar. Have you actually tried compiling and using

Re: Incompatible idioms: relative imports, top-level program file

Rustom Mody wrote: Wanted to try out sympy. apt-install promised ¼ GB download, ¾ GB space usage Just getting a src-tarball was: 6M download, 30M after opening the tar. Have you actually tried compiling and using that tarball, though? Sympy hooks into a lot of other libraries that are

Incompatible idioms: relative imports, top-level program file (was: Setuptools, __init__ and __main__)

. There's no need to explose those in a site package, they normally only need to be local to the application. So the correct idiom is ‘from __future__ import absolute_import’ and keep the application's own implementation imported via relative imports in the same package: ‘from . import

Re: Incompatible idioms: relative imports, top-level program file

On Saturday, February 7, 2015 at 8:43:44 AM UTC+5:30, Rustom Mody wrote: There is on the one hand python modules/packages mechanism with all the hell of dozens of incompatible versions of setuptools/distribute/distutils etc. On the other there is the OS-specific practices/policy such as

Re: Incompatible idioms: relative imports, top-level program file

. If they are not in the Python module path, how are they imported at all? Only absolute imports use the module search path. The whole point of relative imports is to import a module within the same (or a sub-) package, without modifying the search path. URL:https://www.python.org/dev/peps

Re: Incompatible idioms: relative imports, top-level program file

, that relative imports do not work? -- ~Ethan~ [1] which can be a single module signature.asc Description: OpenPGP digital signature -- https://mail.python.org/mailman/listinfo/python-list

Re: Incompatible idioms: relative imports, top-level program file

, they normally only need to be local to the application. If they are not in the Python module path, how are they imported at all? Only absolute imports use the module search path. The whole point of relative imports is to import a module within the same (or a sub-) package, without

[issue10031] Withdraw anti-recommendation of relative imports from documentation

Roundup Robot added the comment: New changeset 8c33440d1f64 by Georg Brandl in branch '3.4': Closes #10031: overhaul the imports section of the programming FAQ. https://hg.python.org/cpython/rev/8c33440d1f64 -- nosy: +python-dev resolution: - fixed stage: patch review - resolved

[issue10031] Withdraw anti-recommendation of relative imports from documentation

Roundup Robot added the comment: New changeset 9d321235f1f9 by Georg Brandl in branch '2.7': Closes #10031: overhaul the imports section of the programming FAQ. https://hg.python.org/cpython/rev/9d321235f1f9 -- ___ Python tracker

[issue10031] Withdraw anti-recommendation of relative imports from documentation

Andy Maier added the comment: Hi, I would like to revive this issue, and have a few comments: 1. In Darren's original proposal, I suggest to say implicit (old-style) relative imports instead of old-style relative imports, because that is the term used in the Python Tutorial (the description

[issue19510] lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line

Éric Araujo added the comment: To be fair to 2to3, that line disrespects some Python best practices (use explicit relative imports (2.5+), put one import per line, group imports by stdlib/non-stdlib). It’s still a bug though :) -- nosy: +benjamin.peterson, eric.araujo

[issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax

: normal status: open title: Whitespace ignored in relative imports: from.package import something is valid syntax type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20240

[issue20240] Whitespace ignored in relative imports: from.package import something is valid syntax

Eric V. Smith added the comment: This is no different from other places in python where white space is optional. As long as the parser can tell the end of a token, there need not be white space before the next token. For example: 1+2 3 1 + 2 3 However, if the parser cannot tell the end of

nosetests vs. relative imports?

Environment: Ubuntu Linux 12.04 (precise) Python 2.7.3 I have a package (i.e. a directory with a __init__.py file). In that directory, I have files math.py and test_math.py; test_math.py contains the single line: from .math import EMA If I run on the command line, nosetests test_math.py

python 2.x and python 3 relative imports and

with symbols 'foo' (first case) or 'pkg1' (second approach). Do you know any other way for relative imports to achieve exactly same effect as with old import semantics? -- https://mail.python.org/mailman/listinfo/python-list

Understanding relative imports in package - and running pytest with relative imports?

and build_table.py are supposed to import from common/shared.py using relative imports. e.g.: from ..common.shared import supplies However, if you then try to run the scripts build_chair.py, or build_table.py, they'll complain about: ValueError: Attempted relative import in non-package

Re: Understanding relative imports in package - and running pytest with relative imports?

On Sun, Nov 24, 2013 at 5:30 PM, Victor Hooi victorh...@gmail.com wrote: The advice seems to be either to run it from the parent directory of furniture with: python -m furniture.chair.build_chair Yes. More pedantically, run it from somewhere such that the furniture package is importable.

[issue19510] lib2to3.fixes.fix_import gets confused if implicit relative imports and absolute imports are on the same line

New submission from Augie Fackler: While tinkering (again) with Mercurial Python 3 messes, I ran across this gem: import error, osutil, encoding, collections (http://selenic.com/hg/file/e1317d3e59e1/mercurial/util.py#l17) That import statement contains 3 relative imports

[issue15623] Init time relative imports no longer work from __init__.so modules

Changes by Brett Cannon br...@python.org: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15623 ___ ___ Python-bugs-list

Relative imports in packages

Hi list, I've these two minor problems which bothered me for quite some time, maybe you can help me. I'm using Python 3.2. For some project I have a component in its own package. Let's say the structure looks like this: pkg/__init__.py pkg/Foo.py pkg/Bar.py Foo.py and Bar.py contain their

[issue15316] runpy swallows ImportError information with relative imports

Georg Brandl added the comment: I don't agree that this is a blocker; would be nice to fix it, of course. -- priority: release blocker - critical ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15316

[issue15316] runpy swallows ImportError information with relative imports

Brett Cannon added the comment: It will get fixed today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15316 ___ ___ Python-bugs-list mailing

[issue15316] runpy swallows ImportError information with relative imports

Brett Cannon added the comment: I am running the test suite now using the secret attribute on ImportError. I tried to pass a flag, but locking became a bit messy/complicated. And I also realized that if I didn't do this then using different implementation of import_ in importlib wouldn't work

[issue15316] runpy swallows ImportError information with relative imports

Roundup Robot added the comment: New changeset ca4bf8e10bc0 by Brett Cannon in branch 'default': Issue #15316: Let exceptions raised during imports triggered by the http://hg.python.org/cpython/rev/ca4bf8e10bc0 -- nosy: +python-dev ___ Python tracker

[issue15316] runpy swallows ImportError information with relative imports

Changes by Brett Cannon br...@python.org: -- resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15316 ___

[issue15316] runpy swallows ImportError information with relative imports

Chris Jerdonek added the comment: Should this issue be fixed before the release? If it is not fixed, certain problems found after the release may become harder to report and diagnose (because the true source of error will be masked). Two months ago issue 15111 which was thought to be the

[issue15316] runpy swallows ImportError information with relative imports

Changes by Jeff Knupp jkn...@gmail.com: -- nosy: +Jeff.Knupp ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15316 ___ ___ Python-bugs-list mailing

[issue15316] runpy swallows ImportError information with relative imports

Brett Cannon added the comment: It has nothing to do with runpy and __main__.py and everything to do with rev 78619:0d52f125dd32 (which fixed issue #15715) which was done to ignore bogus names in fromlist. If you simply change the import line to import foo.bar then you get the expected

  1   2   3   >