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-py
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
> directory and importing the files locall
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
> directory and importing the files locally
Chris Angelico wrote:
> On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi
> 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.
>
On Sat, Apr 9, 2016 at 2:59 AM, Rob Gaddi
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.
>>
>
> Really, no one? It seems like
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
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.
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
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 themsel
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 a
x27;s no need to explose those in a
> > > site package, 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
he
> > 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 modifying the search path.
rts is for libraries [1], and libraries must be in
sys.path. Are you saying that after
placing your top-level file's path in sys.path, 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
ity that its implementation
occupies several sub-modules. 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
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" eve
ort pkg3
import pkg1.pk2.pk3.foo
but this clutters local (bar) namespace 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
On Sun, Nov 24, 2013 at 5:30 PM, Victor Hooi 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. For example, if
ath that.
build_chair.py 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
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 class
This is a copy-paste of a StackOverflow question. Nobody answered
there, but I figured I might have better luck here.
I have a Python 3 project where I'm dynamically importing modules from
disk, using `imp.load_module`. But, I've run into an problem where
relative imports fail, when th
27; individually. It's giving an error:
>
> ImportError: No module named core.folder2
>
> Is this mean when you have created a package where modules are using
> relative imports, they can't execute individually?
The problem is your python-path. Python will put the path of the s
f2b.py
in folder2/f2b.py, I am importing
from core.folder1 import f1a
print f1a.myvar
Now I can't execute 'f2b.py' individually. It's giving an error:
ImportError: No module named core.folder2
Is this mean when you have created a package where modules are using
relative impor
network/
__init__.py
clientlib.py
server.py
- gui/
__init__.py
mainwindow.py
controllers.py
In this structure, for example modules contained in each package may
want to access the helpers utilities through relative imports in
something like:
# network/clientlib.py
f
it__.py
clientlib.py
server.py
- gui/
__init__.py
mainwindow.py
controllers.py
In this structure, for example modules contained in each package may
want to access the helpers utilities through relative imports in
something like:
# network/clientlib.py
from ..helpers.path impor
Chris Colbert wrote:
> It seems the relative import level is dependent on the location of the
> main entry module. I thought the whole idea of relative imports was to
> make the import independent of the entry point?
You don't have to specify it explicitly, so you can move a mod
eter:
>
> def import_segmentation(name):
> return getattr(__import__("segmentation." + name, level=2,
> globals=globals()), name)
>
> Peter
> --
> http://mail.python.org/mailman/listinfo/python-list
>
Many thanks Peter!
Almost like a charm!
It seems the r
Chris Colbert wrote:
> I have package tree that looks like this:
>
> main.py
> package
> __init__.py
> configuration.ini
> server
> __init__.py
> xmlrpc_server.py
> controller.py
> reco
>
> segmentation
> __init__.py
> r
I have package tree that looks like this:
main.py
package
__init__.py
configuration.ini
server
__init__.py
xmlrpc_server.py
controller.py
reco
segmentation
__init__.py
red_objects.py
main.py launches an instance of
On Mar 31, 6:39 pm, Kay Schluehr wrote:
> On 1 Apr., 00:38, Carl Banks wrote:
>
> > On Mar 31, 12:08 pm, Kay Schluehr wrote:
>
> > > > And your proposal is?
>
> > > I have still more questions than answers.
>
> > That's obvious.
>
> > Perhaps you should also refrain from making sweeping negative
On Mar 31, 12:08 pm, Kay Schluehr wrote:
> > And your proposal is?
>
> I have still more questions than answers.
That's obvious.
Perhaps you should also refrain from making sweeping negative
judgments about a system you have more questions than answers about.
(Feel free to make sweeping negativ
On 1 Apr., 00:38, Carl Banks wrote:
> On Mar 31, 12:08 pm, Kay Schluehr wrote:
>
> > > And your proposal is?
>
> > I have still more questions than answers.
>
> That's obvious.
>
> Perhaps you should also refrain from making sweeping negative
> judgments about a system you have more questions tha
Kay Schluehr wrote:
On 31 Mrz., 20:50, Terry Reedy wrote:
Although the ceremony has been performed
basically correct the interpreter god is not pacified and doesn't
respond.
But the import 'ceremony' has not been performed.
There is no import ceremony. Imports are just stated in the source
On 31 Mrz., 20:50, Terry Reedy wrote:
> Nothing is added to sys.modules, except the __main__ module, unless
> imported (which so are on startup).
Yes. The startup process is opaque but at least user defined modules
are not accidentally imported.
>
> > Although the ceremony has been performed
>
Kay Schluehr wrote:
On 31 Mrz., 18:48, s4g wrote:
This and similar solutions ( see Istvan Alberts ) point me to a
fundamental problem of the current import architecture. Suppose you
really want to run a module as a script without a prior import from a
module path:
...A\B\C> python my_module.
On 31 Mrz., 18:48, s4g wrote:
> Hi,
>
> I was looking for a nice idiom for interpackage imports as I found
> this thread.
> Here come a couple of solutions I came up with. Any discussion is
> welcome.
>
> I assume the same file structure
>
> \ App
> | main.py
> +--\subpack1
> | | __init__.py
> | |
Hi,
I was looking for a nice idiom for interpackage imports as I found
this thread.
Here come a couple of solutions I came up with. Any discussion is
welcome.
I assume the same file structure
\ App
| main.py
+--\subpack1
| | __init__.py
| | module1.py
|
+--\subpack2
| | __init__.py
| | module2.p
plicit is better than implicit - and starting with 2.7 -when
> >> "absolute" import semantics will be enabled by default- you'll *have* to
> >> use relative imports inside a package, or fail.
>
> > Really? I thought you would still be able to use
bled by default- you'll *have* to
use relative imports inside a package, or fail.
Really? I thought you would still be able to use absolute imports; you
just won't be able to use implied relative imports instead of explicit
relative imports.
You're right, I put it wrongly. To make
In article ,
Gabriel Genellina wrote:
>
>I'd recommend the oposite - use relative (intra-package) imports when
>possible. Explicit is better than implicit - and starting with 2.7 -when
>"absolute" import semantics will be enabled by default- you'll *have* to
On Mar 25, 1:07 am, Kay Schluehr wrote:
> On 25 Mrz., 05:56, Carl Banks wrote:
>
>
>
>
>
> > On Mar 24, 8:32 pm, Istvan Albert wrote:
>
> > > On Mar 24, 9:35 pm, Maxim Khitrov wrote:
>
> > > > Works perfectly fine with relative imports.
>
ant?
I don't understand, how is this supposed to help relative imports?
That's only because you have not had to deal with the problem that it
solves.
But I had to deal with the problem that it *creates*, even before relative
imports existed, and it's a lot worse.
Bindly inserting
On 25 Mrz., 05:56, Carl Banks wrote:
> On Mar 24, 8:32 pm, Istvan Albert wrote:
>
> > On Mar 24, 9:35 pm, Maxim Khitrov wrote:
>
> > > Works perfectly fine with relative imports.
>
> > This only demonstrates that you are not aware of what the problem
> >
On Mar 24, 8:32 pm, Istvan Albert wrote:
> On Mar 24, 9:35 pm, Maxim Khitrov wrote:
>
> > Works perfectly fine with relative imports.
>
> This only demonstrates that you are not aware of what the problem
> actually is.
>
> Try using relative imports so that it works
On Mar 24, 9:35 pm, Maxim Khitrov wrote:
> Works perfectly fine with relative imports.
This only demonstrates that you are not aware of what the problem
actually is.
Try using relative imports so that it works when you import the module
itself. Now run the module as a program. The same mod
CinnamonDonkey wrote:
> Top responses guys! This has all helped increadibly.
>
> Bearophile,
>
> My applogies if I have offended you, but:
>
> 1. "I can't know much about you from the start" - Is kind of my point.
> Perhaps it would be better to avoid jumping to conclusions and pre-
> judging so
On Tue, Mar 24, 2009 at 8:57 PM, Istvan Albert wrote:
> Does it not bother you that a module that uses relative imports cannot
> be run on its own anymore?
$ python --help
-m mod : run library module as a script (terminates option list)
$ python -m some.module.name
Works perfectly fin
hs
> I don't understand, how is this supposed to help relative imports?
That's only because you have not had to deal with the problem that it
solves.
If you need to have a module that can do both:
1. access relative paths (even other packages)
2. be executable on its own (for example
En Tue, 24 Mar 2009 09:01:01 -0300, R. David Murray
escribió:
CinnamonDonkey wrote:
On 23 Mar, 18:57, bearophileh...@lycos.com wrote:
> CinnamonDonkey:
>
> >what makes something a package?
>
> If you don't know what a package is, then maybe you don't need
> packages.
Thanx for taking the tim
En Tue, 24 Mar 2009 12:49:08 -0300, Istvan Albert
escribió:
On Mar 23, 10:16 am, CinnamonDonkey
wrote:
I'm fairly new to Python so I still have a lot to learn. But I'd like
to know how to correectly use relative imports.
Relative imports are *fundamentally* broken in python. You
On Mar 23, 10:16 am, CinnamonDonkey
wrote:
> I'm fairly new to Python so I still have a lot to learn. But I'd like
> to know how to correectly use relative imports.
Relative imports are *fundamentally* broken in python. You will soon
see that code using relative import will brea
Top responses guys! This has all helped increadibly.
Bearophile,
My applogies if I have offended you, but:
1. "I can't know much about you from the start" - Is kind of my point.
Perhaps it would be better to avoid jumping to conclusions and pre-
judging someones abilities simply because they are
CinnamonDonkey:
> It is neither constructive nor educational.
>
> It's a bit like saying "If you don't know what a function is, then
> maybe you don't need it. ... have you tried having a single block of
> code?"
>
> The point of people coming to these forums is to LEARN and share
> knowledge. Perh
need_ to put a module file into
a subpackage even when they'd only have one module file per subdirectory
and they don't really know what a package is...thus bearophile's (perhaps
poorly phrased) question.
Now that you know what packages are and what the restrictions on relative
imports ar
t; not contain a __init__.py file so it is not a package (i.e. not a
> parent package to "Trac" and "Genshi") :0.
Trac does not use relative imports to access genshi. When relative
imports are not used, python goes through sys.path list to find
modules (with a small excepti
Thanx Max - your explanation sorted it :-), and a big thank you to
everyone else also!
>From the various posts, Python considers any directory containing the
__init__.py file to be a package. The top level package is the highest
directory (closest to root) with a __init__.py file.
Inter-package c
CinnamonDonkey:
>what makes something a package?
If you don't know what a package is, then maybe you don't need
packages.
In your project is it possible to avoid using packages and just use
modules in the same directory?
Bye,
bearophile
--
http://mail.python.org/mailman/listinfo/python-list
which made no difference. I still get exactly
> the same error messages. Perhaps I should have mentioned that I am
> using Python 2.5, which I understand alread supports relative imports
> out of the box. I'll keep this line in for now anyway though :-)
> Cheers!
I wrote http://
En Mon, 23 Mar 2009 13:19:51 -0300, CinnamonDonkey
escribió:
My applogies if this is a silly question... but what makes something a
package?
A package is a directory with an __init__.py file [that Python is aware
of].
and does that mean that what I am trying to do is not
possible ?
Y
On Mon, Mar 23, 2009 at 12:19 PM, CinnamonDonkey
wrote:
> My applogies if this is a silly question... but what makes something a
> package? and does that mean that what I am trying to do is not
> possible ?
A package is a directory that has an __init__.py file. That file can
be empty, or contain
> | | __init__.py
> >> >> | | module2.py
>
> >> >> Module1 needs to access functionality in Module2.
>
> >> >> #module1.py
> >> >> from ..subpack2 import module2
>
> >> >> Seems reasonabl
gt; | | module2.py
>> Module1 needs to access functionality in Module2.
>> #module1.py
>> from ..subpack2 import module2
>> Seems reasonable to me... but it just does not work and I was so
>> liking Python. :(
Another name for relative imports is &
I should have mentioned that I am
> using Python 2.5, which I understand alread supports relative imports
> out of the box. I'll keep this line in for now anyway though :-)
> Cheers!
Sorry, I use that line to avoid conflicts with standard modules, and
forgot that relative imports ar
eyond
toplevel package
Max, thank you for the response... I tried adding "from __future__
import absolute_import" which made no difference. I still get exactly
the same error messages. Perhaps I should have mentioned that I am
using Python 2.5, which I understand alread supports relativ
>> Please, please... please! don't go off on rants about why you think
>> relative imports should not be used. I've got 15+ years in C++ and
>> relative inclusion of other sections of code has never been a
>> problem. As far as I am c
On Mon, Mar 23, 2009 at 10:16 AM, CinnamonDonkey
wrote:
> Hi All,
>
> I'm fairly new to Python so I still have a lot to learn. But I'd like
> to know how to correectly use relative imports.
>
> Please, please... please! don't go off on rants about why you think
Hi All,
I'm fairly new to Python so I still have a lot to learn. But I'd like
to know how to correectly use relative imports.
Please, please... please! don't go off on rants about why you think
relative imports should not be used. I've got 15+ years in C++ and
relativ
On 17 Dez., 11:01, Nicholas wrote:
> I am sure I am not the first to run into this issue, but what is the
> solution?
When you use 2to3 just uncomment or delete the file fix_import.py in
lib2to3/fixes/ .
--
http://mail.python.org/mailman/listinfo/python-list
gt; ..
> ..
>
> if __name__ == '__main__':
> runtests()
>
> But under Python 3.0 this seems impossible. For usual use import a.py
> has to become the line:
>
> from . import a
>
> But if I use that form it is no longer possible to
ain__':
runtests()
But under Python 3.0 this seems impossible. For usual use import a.py
has to become the line:
from . import a
But if I use that form it is no longer possible to run b.py as a
standalone script without raising an error about using relative
imports.
I am sure I am not the fi
Python 3.0 this seems impossible. For usual use import a.py
has to become the line:
from . import a
But if I use that form it is no longer possible to run b.py as a
standalone script without raising an error about using relative
imports.
I am sure I am not the first to run into this issue, but w
Gabriel Genellina wrote:
> En Sun, 31 Aug 2008 07:27:12 -0300, Wojtek Walczak
> <[EMAIL PROTECTED]> escribió:
>
>> On Sun, 31 Aug 2008 06:40:35 GMT, OKB (not okblacke) wrote:
>>
Download the latest beta for your system and give it a try.
>>>
>>> Thanks for the advice, but I'd reall
En Sun, 31 Aug 2008 07:27:12 -0300, Wojtek Walczak <[EMAIL PROTECTED]> escribió:
> On Sun, 31 Aug 2008 06:40:35 GMT, OKB (not okblacke) wrote:
>
>>> Download the latest beta for your system and give it a try.
>>
>> Thanks for the advice, but I'd really rather not deal with
>> installing the e
On Sun, 31 Aug 2008 06:40:35 GMT, OKB (not okblacke) wrote:
>> Download the latest beta for your system and give it a try.
>
> Thanks for the advice, but I'd really rather not deal with
> installing the entire thing alongside my existing version, possibly
> causing conflicts in who knows w
Terry Reedy wrote:
>
>> So, will relative imports in Python 3.0 allow things like
>> "import
>> ..relative.importing.path as prettyname"? If not, why not?
>
> Download the latest beta for your system and give it a try.
So, will relative imports in Python 3.0 allow things like "import
..relative.importing.path as prettyname"? If not, why not?
Download the latest beta for your system and give it a try.
--
http://mail.python.org/mailman/listinfo/python-list
I was looking at PEP 328. It says that relative imports with the
dot syntax will only be allowed with the "from" import variety (e.g.,
"from ..somemodule import somename"). The reason given for this in the
PEP is that after import xxx.yyy, "xxx.yyy" is
Carl: Your solution is kind of what I was leaning towards after a bit
of thinking. Since I have to have the modules each have their own
detect() method, then it wouldn't be too hard to have their own test()
method to put them through their paces.
Catrironpi: I will look into this as it might hel
nd.
> I would prefer to be able to test the file without adding anything to
> the PYTHONPATH, like I said by using the name == main trick.
>
> So could someone explain to me what the rationale behind not allowing
> parent directory relative imports is? And possibly what I can do to
> g
en
when I try the
'from __future__ import absolute_import' command.
I would prefer to be able to test the file without adding anything to
the PYTHONPATH, like I said by using the name == main trick.
So could someone explain to me what the rationale behind not allowing
parent directory rela
le. Is there any way to achieve the "bar.baz" name with relative
imports?
--
http://mail.python.org/mailman/listinfo/python-list
ot;Note that both explicit and implicit 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 should always use absolute imports."
The distinction between
moduleY
File "/home/bronger/temp/packages-test/package/moduleY.py", line 1, in
from . import moduleX
ImportError: cannot import name moduleX
If I turn the relative imports to absolute ones, it works. But I'd
prefer the relative notation for intra-package imports.
Pat O'Hara wrote:
> Hey guys, I know this is a really stupid question, but I've tried
> googling and nothing came up. I also tried IRC, but it was too crowded
> and I didn't get much useful information.
>
> I'm using Python 2.5 on WinXP, and I'm trying to do a relative import.
> Here's the pack
Hey guys, I know this is a really stupid question, but I've tried
googling and nothing came up. I also tried IRC, but it was too crowded
and I didn't get much useful information.
I'm using Python 2.5 on WinXP, and I'm trying to do a relative import.
Here's the package structure
A/
__init__.
On 4/9/07, Echo <[EMAIL PROTECTED]> wrote:
> Here is my setup:
> rpg
> -objects
> --__init__.py
> --gameobject.py
> --material.py
> -__init__.py
> -run_tests.py
> -stats.py
>
> the contents of run_test.py is:
> import objects as o
>
> the contents of objects/__init__.py is:
> from material import *
Here is my setup:
rpg
-objects
--__init__.py
--gameobject.py
--material.py
-__init__.py
-run_tests.py
-stats.py
the contents of run_test.py is:
import objects as o
the contents of objects/__init__.py is:
from material import *
in objects/material.py I have:
from .gameobject import GameObject
fro
In article <[EMAIL PROTECTED]>,
Alexander Eisenhuth <[EMAIL PROTECTED]> wrote:
>
>PyLint says that "Relative imports" ... are worth to be warned .
>
>And I ask myself why?
http://www.python.org/dev/peps/pep-0328
--
Aahz ([EMAIL PROTECTED]) <*>
Hi,
PyLint says that "Relative imports" ... are worth to be warned .
And I ask myself why?
- Example directory structure -
Sound/ Top-level package
__init__.py Initialize the sound package
Robert Kern wrote:
> Remember that this is code in the A.B.C module.
Oh! That clears it all up! I wasn't realizing that the import statements
were being executed from within the C module! Thanks! :)
--
http://mail.python.org/mailman/listinfo/python-list
John Salerno wrote:
> Robert Kern wrote:
>
>> What is ambiguous about A.B.D, A.E, and A.F.G? But if you like:
>
> I guess maybe I was looking at it backwards. From the way it was worded,
> I thought the only information we had to use was the structure A.B.C,
> and then given a statement like:
>
John Salerno wrote:
> Robert Kern wrote:
>
> > What is ambiguous about A.B.D, A.E, and A.F.G? But if you like:
>
> I guess maybe I was looking at it backwards. From the way it was worded,
> I thought the only information we had to use was the structure A.B.C,
> and then given a statement like:
>
>
Robert Kern wrote:
> What is ambiguous about A.B.D, A.E, and A.F.G? But if you like:
I guess maybe I was looking at it backwards. From the way it was worded,
I thought the only information we had to use was the structure A.B.C,
and then given a statement like:
from . import D
we just had to f
John Salerno wrote:
> I'm reading the "What's New" section of the 2.5 docs, and I'm a little
> confused by the last section of "Absolute and Relative Imports":
>
> ---
> For example, cod
I'm reading the "What's New" section of the 2.5 docs, and I'm a little
confused by the last section of "Absolute and Relative Imports":
---
For example, code in the A.B.C module can do:
from . import D
Chris wrote:
After reading that link I tried to change my imports like this:
" from .myPythonFileInTheSameFolder import MyClass"
This style of import is not yet implemented.
I'm getting more and more confused...
How can I correctly do a relative import ?
I think your choices are
- keep doing what y
After reading that link I tried to change my imports like this:
" from .myPythonFileInTheSameFolder import MyClass"
Well, this caused an error in PyLint:
Encountered "." at line 1, column 6. Was expecting one of: "or" ...
"and" ... "not" ... "is" ... "in" ... "lambda" ...
Michael Hoffman wrote:
Chris wrote:
Why do relative imports cause warnings in PyLint?
http://www.python.org/peps/pep-0328.html#rationale-for-absolute-imports
I notice that this section says that
from __future__ import absolute_import
will be a feature of Python 2.4. Apparently it didn't
Chris wrote:
Why do relative imports cause warnings in PyLint?
http://www.python.org/peps/pep-0328.html#rationale-for-absolute-imports
--
Michael Hoffman
--
http://mail.python.org/mailman/listinfo/python-list
Why do relative imports cause warnings in PyLint?
A warning like this:
ID:W0403 Relative import 'myPythonFileInTheSameFolder'
When the import is like:
from myPythonFileInTheSameFolder import MyClass
--
http://mail.python.org/mailman/listinfo/python-list
I've noticed the push by Guido and others to use absolute imports
instead of relative imports. I've always enjoyed the ease of relative
imports, but am starting to understand that "explicit is better than
implicitly" as the Python philosophy goes. I'm trying to develo
100 matches
Mail list logo
