Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #41805 > unrolled thread

import in Python3.3

Back to article view | Back to comp.lang.python

Contents

  import in Python3.3 Fabian von Romberg <fromberg100@hotmail.com> - 2013-03-24 18:12 -0500
    Re: import in Python3.3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-25 00:27 +0000
      Re: import in Python3.3 Fabian von Romberg <fromberg100@hotmail.com> - 2013-03-24 20:39 -0500
      Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-25 20:49 -0700
        Re: import in Python3.3 Jerry Hill <malaclypse2@gmail.com> - 2013-03-26 12:33 -0400
          Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-26 11:41 -0700
          Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-26 11:41 -0700
          Re: import in Python3.3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-26 23:11 +0000

#41805 — import in Python3.3

Hi,

I have a package name collections and inside of my package I want to import the collections package from the standard library, but there is name conflicts.

How do I import explicitly from the standard library?

Im working on Python3.3

Thanks in advance and regards,
Fabian

[toc] | [next] | [standalone]

#41807

On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:

> Hi,
> 
> I have a package name collections and inside of my package I want to
> import the collections package from the standard library, but there is
> name conflicts.
> 
> How do I import explicitly from the standard library?

You can't. However, you can import explicitly from your package, or 
implicitly by using a relative import.

Starting from Python 2.7, the "import" statement is always absolute. So 
the line:

  import collections

will always find the first *top level* module or package "collections" in 
the python search path. See below for an important proviso.

Inside your package, you can either use an explicit import like this:

  import mypackage.collections as collections

or use a relative import like this:

  from . import collections

Here is a concrete example. I create a package containing five files:

mypackage/
+-- __init__.py
+-- collections.py
+-- absolute_import.py
+-- explicit_import.py
+-- relative_import.py

with the following content:

# absolute_import.py
import collections

# explicit_import.py 
import mypackage.collections as collections

# relative_import.py 
from . import collections


The other two files (collections.py and __init__.py) can be blank. Now, 
from *outside* the package, I can do this:


py> import mypackage.absolute_import
py> import mypackage.explicit_import
py> import mypackage.relative_import
py> 
py> mypackage.absolute_import.collections
<module 'collections' from '/usr/local/lib/python3.3/collections/__init__.py'>
py> mypackage.explicit_import.collections
<module 'mypackage.collections' from './mypackage/collections.py'>
py> mypackage.relative_import.collections
<module 'mypackage.collections' from './mypackage/collections.py'>


Of course "from mypackage import absolute_import" etc. will also work.


However, beware: if you cd into the package directory, and then launch 
Python, the current directory will contain a file "collections.py" which 
will shadow the standard library collections.py. So don't do that.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#41810

Hi Steven,

thanks a lot for the explanation.

I will keep in mind not to use names for my modules that can shadow the standard library.

Regards,
Fabian

On 03/24/2013 07:27 PM, Steven D'Aprano wrote:
> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
> 
>> Hi,
>>
>> I have a package name collections and inside of my package I want to
>> import the collections package from the standard library, but there is
>> name conflicts.
>>
>> How do I import explicitly from the standard library?
> 
> You can't. However, you can import explicitly from your package, or 
> implicitly by using a relative import.
> 
> Starting from Python 2.7, the "import" statement is always absolute. So 
> the line:
> 
>   import collections
> 
> will always find the first *top level* module or package "collections" in 
> the python search path. See below for an important proviso.
> 
> Inside your package, you can either use an explicit import like this:
> 
>   import mypackage.collections as collections
> 
> or use a relative import like this:
> 
>   from . import collections
> 
> Here is a concrete example. I create a package containing five files:
> 
> mypackage/
> +-- __init__.py
> +-- collections.py
> +-- absolute_import.py
> +-- explicit_import.py
> +-- relative_import.py
> 
> with the following content:
> 
> # absolute_import.py
> import collections
> 
> # explicit_import.py 
> import mypackage.collections as collections
> 
> # relative_import.py 
> from . import collections
> 
> 
> The other two files (collections.py and __init__.py) can be blank. Now, 
> from *outside* the package, I can do this:
> 
> 
> py> import mypackage.absolute_import
> py> import mypackage.explicit_import
> py> import mypackage.relative_import
> py> 
> py> mypackage.absolute_import.collections
> <module 'collections' from '/usr/local/lib/python3.3/collections/__init__.py'>
> py> mypackage.explicit_import.collections
> <module 'mypackage.collections' from './mypackage/collections.py'>
> py> mypackage.relative_import.collections
> <module 'mypackage.collections' from './mypackage/collections.py'>
> 
> 
> Of course "from mypackage import absolute_import" etc. will also work.
> 
> 
> However, beware: if you cd into the package directory, and then launch 
> Python, the current directory will contain a file "collections.py" which 
> will shadow the standard library collections.py. So don't do that.
> 
> 
> 

[toc] | [prev] | [next] | [standalone]

#41849

On Sunday, March 24, 2013 8:27:56 PM UTC-4, Steven D'Aprano wrote:
> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
> 
> 
> 
> > Hi,
> 
> > 
> 
> > I have a package name collections and inside of my package I want to
> 
> > import the collections package from the standard library, but there is
> 
> > name conflicts.
> 
> > 
> 
> > How do I import explicitly from the standard library?
> 
> 
> 
> You can't. However, you can import explicitly from your package, or 
> 
> implicitly by using a relative import.
> 
> 
> 
> Starting from Python 2.7, the "import" statement is always absolute. So 
> 
> the line:
> 
> 
> 
>   import collections
> 
> 
> 
> will always find the first *top level* module or package "collections" in 
> 
> the python search path. See below for an important proviso.
> 
> 
> 
> Inside your package, you can either use an explicit import like this:
> 
> 
> 
>   import mypackage.collections as collections
> 
> 
> 
> or use a relative import like this:
> 
> 
> 
>   from . import collections
> 
> 
> 
> Here is a concrete example. I create a package containing five files:
> 
> 
> 
> mypackage/
> 
> +-- __init__.py
> 
> +-- collections.py
> 
> +-- absolute_import.py
> 
> +-- explicit_import.py
> 
> +-- relative_import.py
> 
> 
> 
> with the following content:
> 
> 
> 
> # absolute_import.py
> 
> import collections
> 
> 
> 
> # explicit_import.py 
> 
> import mypackage.collections as collections
> 
> 
> 
> # relative_import.py 
> 
> from . import collections
> 
> 
> 
> 
> 
> The other two files (collections.py and __init__.py) can be blank. Now, 
> 
> from *outside* the package, I can do this:
> 
> 
> 
> 
> 
> py> import mypackage.absolute_import
> 
> py> import mypackage.explicit_import
> 
> py> import mypackage.relative_import
> 
> py> 
> 
> py> mypackage.absolute_import.collections
> 
> <module 'collections' from '/usr/local/lib/python3.3/collections/__init__.py'>
> 
> py> mypackage.explicit_import.collections
> 
> <module 'mypackage.collections' from './mypackage/collections.py'>
> 
> py> mypackage.relative_import.collections
> 
> <module 'mypackage.collections' from './mypackage/collections.py'>
> 
> 
> 
> 
> 
> Of course "from mypackage import absolute_import" etc. will also work.
> 
> 
> 
> 
> 
> However, beware: if you cd into the package directory, and then launch 
> 
> Python, the current directory will contain a file "collections.py" which 
> 
> will shadow the standard library collections.py. So don't do that.

I find this kind of thing sad: it feels to me that programmers are working around somewhat arbitrary and changing restrictions. Rather than avoid names like "collections", why not try to address the underlying problem? There isn't an ambiguity here in my view: the fullname is mypackage.collections

It was for this reason I wrote import_relative http://code.google.com/p/pyimport-relative/. 

It is far from perfect, but it pleases me to think that I one can adjust the language to do reasonable things rather than having it bend me into figuring out what's out there and limit the choice of names I use in submodules. 

> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

[toc] | [prev] | [next] | [standalone]

#41920

On Mon, Mar 25, 2013 at 11:49 PM, rocky <rocky@gnu.org> wrote:
>> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
>> > I have a package name collections and inside of my package I want to

> I find this kind of thing sad: it feels to me that programmers are working around somewhat arbitrary and changing restrictions. Rather than avoid names like "collections", why not try to address the underlying problem? There isn't an ambiguity here in my view: the fullname is mypackage.collections

You've said a couple of times now that the original author has a
package named "mypackage" with a module "collections" in it.  As far
as I can tell, that's untrue.  The original post claims to have a
package named "collections", which is colliding with the builtin
module of the same name.

As far as I can tell, all of your suggestions about using your
pyimport-relative tool aren't helpful unless the author re-names his
package from "collections" to "mypackage" and then moves all of their
code into a "collections" module inside "mypackage", right?

-- 
Jerry

[toc] | [prev] | [next] | [standalone]

#41936

On Tuesday, March 26, 2013 12:33:54 PM UTC-4, Jerry Hill wrote:
> On Mon, Mar 25, 2013 at 11:49 PM, rocky wrote:
> 
> >> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
> 
> >> > I have a package name collections and inside of my package I want to
> 
> 
> 
> > I find this kind of thing sad: it feels to me that programmers are working around somewhat arbitrary and changing restrictions. Rather than avoid names like "collections", why not try to address the underlying problem? There isn't an ambiguity here in my view: the fullname is mypackage.collections
> 
> 
> 
> You've said a couple of times now that the original author has a
> 
> package named "mypackage" with a module "collections" in it.  As far
> 
> as I can tell, that's untrue.  The original post claims to have a
> 
> package named "collections", which is colliding with the builtin
> 
> module of the same name.
> 
> 
> 
> As far as I can tell, all of your suggestions about using your
> 
> pyimport-relative tool aren't helpful unless the author re-names his
> 
> package from "collections" to "mypackage" and then moves all of their
> 
> code into a "collections" module inside "mypackage", right?

Right. Perhaps then I misunderstand. Having a package called "collections" when there is something out there already called "collections" clearly ill advised. 

But in that case, using sys.path to get around this is still a bad idea: the clash should be fixed. Sure, only in the case that this really can't be addressed would I use sys.path.

> 
> 
> 
> -- 
> 
> Jerry

[toc] | [prev] | [next] | [standalone]

#41937

On Tuesday, March 26, 2013 12:33:54 PM UTC-4, Jerry Hill wrote:
> On Mon, Mar 25, 2013 at 11:49 PM, rocky wrote:
> 
> >> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
> 
> >> > I have a package name collections and inside of my package I want to
> 
> 
> 
> > I find this kind of thing sad: it feels to me that programmers are working around somewhat arbitrary and changing restrictions. Rather than avoid names like "collections", why not try to address the underlying problem? There isn't an ambiguity here in my view: the fullname is mypackage.collections
> 
> 
> 
> You've said a couple of times now that the original author has a
> 
> package named "mypackage" with a module "collections" in it.  As far
> 
> as I can tell, that's untrue.  The original post claims to have a
> 
> package named "collections", which is colliding with the builtin
> 
> module of the same name.
> 
> 
> 
> As far as I can tell, all of your suggestions about using your
> 
> pyimport-relative tool aren't helpful unless the author re-names his
> 
> package from "collections" to "mypackage" and then moves all of their
> 
> code into a "collections" module inside "mypackage", right?

Right. Perhaps then I misunderstand. Having a package called "collections" when there is something out there already called "collections" clearly ill advised. 

But in that case, using sys.path to get around this is still a bad idea: the clash should be fixed. Sure, only in the case that this really can't be addressed would I use sys.path.

> 
> 
> 
> -- 
> 
> Jerry

[toc] | [prev] | [next] | [standalone]

#41962

On Tue, 26 Mar 2013 12:33:54 -0400, Jerry Hill wrote:

> On Mon, Mar 25, 2013 at 11:49 PM, rocky <rocky@gnu.org> wrote:
>>> On Sun, 24 Mar 2013 18:12:49 -0500, Fabian von Romberg wrote:
>>> > I have a package name collections and inside of my package I want to
> 
>> I find this kind of thing sad: it feels to me that programmers are
>> working around somewhat arbitrary and changing restrictions. Rather
>> than avoid names like "collections", why not try to address the
>> underlying problem? There isn't an ambiguity here in my view: the
>> fullname is mypackage.collections
> 
> You've said a couple of times now that the original author has a package
> named "mypackage" with a module "collections" in it.  As far as I can
> tell, that's untrue.  The original post claims to have a package named
> "collections", which is colliding with the builtin module of the same
> name.

Ah, that would be my fault. I was the first one to mention "mypackage", 
and I misread the OP's description.

Given that he has a *top-level* package "collections" which clashes with 
the collections in the standard library, there's no simple way to bypass 
his package and find the standard library collections module. When you 
have two top-level modules/packages with the same name, whichever one 
comes first in sys.path will shadow the second one.


-- 
Steven

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web