[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 ___

[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. --

[issue34414] Absolute imports conflict with local files

Ronald Oussoren added the comment: This behaviour is not a bug, even if it can be confusing at times. Please read . -- resolution: -> not a bug status: open -> closed ___ Python tracker

[issue34414] Absolute imports conflict with local files

Jonathan Hadida added the comment: With regards to "This has nothing to do with absolute imports at all.", I would like to point out that the "import math" statement that I am complaining about IS WITHIN THE NUMPY MODULE. So it seems very related to this bug.

[issue34414] Absolute imports conflict with local files

Jonathan Hadida added the comment: Thanks again for your reply, I really appreciate your time. Every language I know has reserved keywords, and a restricted syntax. Nothing to complain about there. Banning the use of tabs (PEP8) is pretty odd; but restricting file-names is just a whole new

[issue34414] Absolute imports conflict with local files

Ronald Oussoren added the comment: This has nothing to do with absolute imports at all. You have two toplevel modules in an entry on sys.path that is before the stdlib (see the earlier message by Eric V. Smit for documentation on how the path is initialised). The name of one of those

[issue34414] Absolute imports conflict with local files

Eric V. Smith added the comment: See https://docs.python.org/3/tutorial/modules.html#the-module-search-path Calling this a "hack", and "crazy", is not the way to get volunteers to help you with your issue. Please show a little more tolerance, please. -- nosy: +eric.smith

[issue34414] Absolute imports conflict with local files

that local files conflict with absolute imports _within dependent modules_ is nothing short of a hack (think from the point of view of the dependencies themselves), and IMO clearly conflicts with the idea of absolute imports in the first place. This is crazy! -- status: pending -> o

[issue34414] Absolute imports conflict with local files

adows the stdlib module "math". This has nothing to do with absolute imports. That is shown by "python3.6 -m foo.a". This runs the code in foo/a.py as module foo.a, and "math.py" is now only accessible as "foo.math" (it won't shadow the builtin module "

[issue34414] Absolute imports conflict with local files

to the post on StackOverflow indicate that this behaviour could only be reproduced on Windows and Linux using conda with late versions of Python. THE ISSUE - Absolute imports seem to conflict with local files (not in any module). This is at odds with the documented behaviour (https

[issue29351] absolute imports for logging

Changes by Vinay Sajip : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29351] absolute imports for logging

Vinay Sajip added the comment: > No, we cannot consider these changes under any circumstances for 2.7 because > ... Well, it would change import behaviour in a backwards-incompatible way, wouldn't it? -- ___ Python tracker

[issue29351] absolute imports for logging

Markus Gerstel added the comment: Yes, this is indeed the same for other stdlib modules, too. Logging is just the first one that came to attention in our investigations. I haven't prepared any other patches yet though, because your answer could easily be "No, we cannot consider these changes

[issue29351] absolute imports for logging

Vinay Sajip added the comment: There's nothing particular about logging here, is there? Any of the 2.7 stdlib modules will exhibit similar behaviour, since that __future__ import is not in general defined in the stdlib modules, other than in the test suite. --

[issue29351] absolute imports for logging

Changes by Dries Desmet : -- nosy: +dries_desmet ___ Python tracker ___ ___ Python-bugs-list

[issue29351] absolute imports for logging

Changes by Markus Gerstel : -- nosy: +vinay.sajip ___ Python tracker ___ ___

[issue29351] absolute imports for logging

Add 'from __future__ import absolute_import' to all files in the logging directory. A relevant patch is attached. -- components: Library (Lib) files: 0001-absolute-import.patch keywords: patch messages: 286083 nosy: mgerstel priority: normal severity: normal status: open title: absolu

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

Nick Coghlan added the comment: We seem to be talking past each other, so let's take a step back and ensure we have a common understanding of the absolute/relative terminology: "import x.y.z" is an absolute import "from x.y import z" is still an absolute import. "from . import z" is an

[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

You also said that "PEP 8 prescribes a way of doing something that often won't work" which I disagree with. I think you're reading "absolute import" as synonymous with `import ...` which is not what the term means. In actuality, absolute imports means no leading dot in th

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

" form as a way to avoid name clashes. So PEP 8 promotes absolute imports, and then it presents using "import" instead of "from ... import" as a solution to some problems. It never mentions that the 'as' clause could also solve those problems, and also never mentions

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

be modified. If it's not bad code, then the docs shouldn't denigrate the coding style (especially not to the extent of requiring absolute imports in standard library code), because a lot of newbies take the docs to heart and spend a lot of time and energy beating up themselves and others about

[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

Patrick Maupin added the comment: The PEP 8 recommendation to "use absolute imports" is completely, totally, unambiguously meaningless absent the expectation that packages refer to parts of themselves. And it works, too! (For a single level of package.) As soon as packages

[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

Patrick Maupin added the comment: I'm a big fan of stitching things together at the top myself -- maybe that's partly an unconscious reaction to this very issue. But I'm not sanguine about how easy it is to express this practice in the docs. This issue arose in the context of me answering a

[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 ___ ___

[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

Absolute imports?

http://docs.python.org/2/whatsnew/2.5.html says: Once absolute imports are the default, import string will always find the standard library¹s version. Experimentally, it appears that modules in site-packages are also found by absolute imports. I wouldn't consider site-packages to be part

Re: Absolute imports?

On Sun, Feb 16, 2014 at 2:06 AM, Roy Smith r...@panix.com wrote: It also says, This absolute-import behaviour will become the default in a future version (probably Python 2.7), but it appears that 2.7.6 is still doing relative by default. Since absolute imports can be controlled with a future

Re: Absolute imports?

Roy Smith wrote: http://docs.python.org/2/whatsnew/2.5.html says: Once absolute imports are the default, import string will always find the standard library¹s version. Experimentally, it appears that modules in site-packages are also found by absolute imports. I wouldn't consider site

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

if implicit relative imports and absolute imports are on the same line versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19510 ___ ___ Python

[issue16570] Absolute imports fail to take full path into account?

/home/djc/src/test/pkg/tests/http.py, line 1, in module from pkg import http ImportError: cannot import name http -- components: Interpreter Core messages: 176545 nosy: brett.cannon, djc, ncoghlan priority: normal severity: normal status: open title: Absolute imports fail to take full

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: This test example is nonsensical. You are directly executing a package which leads to pkg/tests being put in sys.path first. That means you end up with http in pkg/tests masking the one in the stdlib, which causes your ``from http.clients import

[issue16570] Absolute imports fail to take full path into account?

Dirkjan Ochtman added the comment: It's not nonsensical. Something exactly like it came up while I was looking into porting couchdb-python to Python 3. couchdb-python has had a couchdb.http module for a while now; it didn't start clashing with the stdlib until Python 3. Also, I don't

[issue16570] Absolute imports fail to take full path into account?

Dirkjan Ochtman added the comment: Never mind, I get what you're getting at now. I thought that the cwd was added to the sys.path, not the containing directory for the executed script. I'll look into using __main__. Thanks! -- ___ Python tracker

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: When you execute a module on the command line, sys.path[0] is set to that containing directory (e.g. pkg/tests in your example; just have pkg/tests/__init__.py print out sys.path to see what I mean). ``import http`` is going to look on sys.path no matter what,

[issue16570] Absolute imports fail to take full path into account?

Brett Cannon added the comment: Glad it makes sense now. =) I was writing my reply while you sent yours. Anyway, your PYTHONPATH setting goes on to sys.path *after* the directory containing the script being executed. This is so that when you execute Python code somewhere it will get the local

[issue16570] Absolute imports fail to take full path into account?

Eric Snow added the comment: Things are working as they should here. The key points: * when running a script, sys.path[0] is set to the script's directory (with no script sys.path[0] is set to the CWD, see issue13475), * pkg/tests/__init__.py is loaded and executed twice: once as the script

[issue16570] Absolute imports fail to take full path into account?

Eric Snow added the comment: oops. too slow. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16570 ___ ___ Python-bugs-list mailing list

[issue7844] Add -3 warning for absolute imports.

Changes by Mark Dickinson dicki...@gmail.com: -- resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844 ___

Re: how to run python2.6 module with absolute imports stand alone

Gelonida N wrote: On 09/08/2012 02:13 AM, Mark Lawrence wrote: [snip] I hope this helps http://stackoverflow.com/questions/3616952/how-to-properly-use-relative-or-absolute-imports-in-python-modules It seems the safest bet seems to be to not use relative imports. That's what I figured

Re: how to run python2.6 module with absolute imports stand alone

it and then call the main function of the imported module. Not very elegant, but probably functional. Thanks in advance for any other suggestions / ideas. I hope this helps http://stackoverflow.com/questions/3616952/how-to-properly-use-relative-or-absolute-imports-in-python-modules It seems

how to run python2.6 module with absolute imports stand alone

Hi, many of my modules contain following section at the end def main(): do_something() if __name__ == '__main__': main() This allows me to run some basic example code or some small test in a stand alone mode. My new modules contain following line at the beginning: from __future__

Re: how to run python2.6 module with absolute imports stand alone

module. Not very elegant, but probably functional. Thanks in advance for any other suggestions / ideas. I hope this helps http://stackoverflow.com/questions/3616952/how-to-properly-use-relative-or-absolute-imports-in-python-modules -- Cheers. Mark Lawrence. -- http://mail.python.org

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset cc9e5ddd8220 by Petri Lehtinen in branch '2.7': #14494: Document that absolute imports became default in 3.0 instead of 2.7. http://hg.python.org/cpython/rev/cc9e5ddd8220 New changeset 7cdc1392173f by Petri Lehtinen

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

Petri Lehtinen pe...@digip.org added the comment: Fixed, thanks for the patch. BTW, you should sign the PSF Contributor Agreement. See http://www.python.org/psf/contrib/. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

Changes by Petri Lehtinen pe...@digip.org: -- nosy: +petri.lehtinen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14494 ___ ___ Python-bugs-list

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

New submission from Sven Marnach s...@marnach.net: As has been pointed out before on python-dev [1], the mandatory version of '__future__.absolute_import' does not match reality. In Python 2.7, absolute imports are not the default. [1]: http://article.gmane.org/gmane.comp.python.devel/125446

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

Changes by R. David Murray rdmur...@bitdance.com: -- stage: - patch review versions: -Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14494 ___

[issue14494] __future__.py and its documentation claim absolute imports became mandatory in 2.7, but they didn't

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14494 ___ ___ Python-bugs-list

Re: Absolute imports?

Roy Smith wrote: [snip] It's reasonably straight-forward to figure out that absolute path, starting from sys.argv[0] and using the tools in os.path. Now I need to import the file, given that I know its absolute pathname. It looks like imp.load_source() does what I want, I'm just wondering

Re: Absolute imports?

Roy Smith r...@panix.com writes: Ben Finney ben+pyt...@benfinney.id.au wrote: What is the problem you're trying to solve? It is likely we can suggest a better solution. Well, the problem I'm trying to solve is that I have an absolute pathname to a python source file that I want to import

Re: Absolute imports?

Ben Finney ben+pyt...@benfinney.id.au writes: The filesystem path (if any!) is derived from the name that the module will be bound to within the code. That'w why the indirection of ‘sys.path’ is necessary: it keeps the mapping between module names and filesystem paths. That phrasing gives

Absolute imports?

If I have an absolute path to a file (i.e. '/home/roy/foo.py'), is there a way to import that as a module WITHOUT modifying sys.path? I'm using Python 2.6. I've read PEP 328, and don't really understand how the absolute imports it's talking about are supposed to work. Should I be using

Re: Absolute imports?

of modules in Lib/site-packages. But why the horror of modifying sys.path? It is normal proceedure. I've read PEP 328, and don't really understand how the absolute imports it's talking about are supposed to work. Those are the normal imports that start from a directory in sys.path. Relative

Re: Absolute imports?

* related to its filesystem path. What is the problem you're trying to solve? It is likely we can suggest a better solution. I've read PEP 328, and don't really understand how the absolute imports it's talking about are supposed to work. Should I be using imp.load_source()? PEP 328 introduces

Re: Absolute imports?

In article 877heff4fl@benfinney.id.au, Ben Finney ben+pyt...@benfinney.id.au wrote: Roy Smith r...@panix.com writes: If I have an absolute path to a file (i.e. '/home/roy/foo.py'), is there a way to import that as a module WITHOUT modifying sys.path? I'm using Python 2.6.

Re: Absolute imports?

In article mailman.658.1294522447.6505.python-l...@python.org, Terry Reedy tjre...@udel.edu wrote: Import from another file in /home/roy. (since '.' is part of sys.path). Or put module or package of modules in Lib/site-packages. But why the horror of modifying sys.path? It is normal

Re: Absolute imports?

On 1/8/2011 5:48 PM, Roy Smith wrote: In articlemailman.658.1294522447.6505.python-l...@python.org, Terry Reedytjre...@udel.edu wrote: Import from another file in /home/roy. (since '.' is part of sys.path). Or put module or package of modules in Lib/site-packages. But why the horror of

[issue4212] email.LazyImporter does not use absolute imports

R. David Murray rdmur...@bitdance.com added the comment: LazyImporter isn't used in Python3. Without someone motivated to propose a patch this isn't going to be changed, so I'm closing the issue. -- resolution: - wont fix stage: - committed/rejected status: open - closed

[issue7844] Add -3 warning for absolute imports.

Ezio Melotti ezio.melo...@gmail.com added the comment: Benjamin, are we still in time for this if someone provides a patch? -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844

[issue7844] Add -3 warning for absolute imports.

Benjamin Peterson benja...@python.org added the comment: Yes, if soonish. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844 ___ ___

[issue4212] email.LazyImporter does not use absolute imports

Changes by Barry A. Warsaw ba...@python.org: -- assignee: barry - r.david.murray nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4212 ___

[issue7844] Add -3 warning for absolute imports.

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844 ___ ___ Python-bugs-list mailing list

[issue7844] Add -3 warning for absolute imports.

Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti priority: - normal stage: - needs patch type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844

[issue7844] Add -3 warning for absolute imports.

New submission from Mark Dickinson dicki...@gmail.com: It would be good to have a -3 warning for any use of import in 2.7 whose semantics change in 3.x, as a result of the absolute imports PEP (PEP 328). -- components: Interpreter Core messages: 98781 nosy: mark.dickinson severity

[issue7844] Add -3 warning for absolute imports.

Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7844 ___ ___ Python-bugs-list mailing

[issue4152] ihooks module cannot handle absolute imports

Neil Schemenauer nas-pyt...@arctrix.com added the comment: Fixed in SVN rev 75423. -- nosy: +nascheme resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4152

Absolute imports in Python 2.4

I have a package which includes a module which shadows a module in the standard library. For example: package +-- __init__.py +-- ham.py +-- spam.py +-- sys.py Inside that package, I want to import the standard library sys. In other words, I want an absolute import. In Python 2.7, absolute

Re: Absolute imports in Python 2.4

En Mon, 01 Jun 2009 21:40:26 -0300, Steven D'Aprano st...@remove-this-cybersource.com.au escribió: I have a package which includes a module which shadows a module in the standard library. For example: package +-- __init__.py +-- ham.py +-- spam.py +-- sys.py Inside that package, I want to

[issue4152] ihooks module cannot handle absolute imports

Neil Schemenauer nas-pythonb...@arctrix.com added the comment: Adding a patch that adds support for relative imports based on the import.c code. I've tested it by hacking the test_import.py test module. -- versions: +Python 2.7 Added file:

[issue4212] email.LazyImporter does not use absolute imports

Martin v. Löwis [EMAIL PROTECTED] added the comment: No patch has been proposed, so the issue is not eligible for 2.5.3. -- nosy: +loewis versions: +Python 2.6 -Python 2.5.3 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4212

[issue4212] email.LazyImporter does not use absolute imports

Changes by Benjamin Peterson [EMAIL PROTECTED]: -- assignee: - barry nosy: +barry ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4212 ___ ___

[issue4152] ihooks module cannot handle absolute imports

New submission from Neil Schemenauer [EMAIL PROTECTED]: The ihooks module was updated when the absolute imports feature was implemented. At a minimum, I guess the import_module() methods in that module would need to have level=-1 keyword arguments added. The only library in the core that uses

absolute imports (python-2.5)

Hello all I just played around a bit with python 2.5 and relative imports. Bit disappointed so far. Hoped to be able to use this new feature to develop standalone libraries that can be just dropped into any project without having to adjust any imports. pkg/ pkg/__init__.py pkg/main.py