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

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

Re: import in Python3.3

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: import in Python3.3 Terry Reedy <tjreedy@udel.edu> - 2013-03-26 03:04 -0400
    Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-26 08:37 -0700
      Re: import in Python3.3 Phil Connell <pconnell@gmail.com> - 2013-03-26 21:16 +0000
      Re: import in Python3.3 Rocky Bernstein <rocky@gnu.org> - 2013-03-26 18:24 -0400
      Re: import in Python3.3 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-03-26 23:06 +0000
        Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-26 17:33 -0700
    Re: import in Python3.3 rocky <rocky@gnu.org> - 2013-03-26 08:37 -0700

#41860 — Re: import in Python3.3

On 3/24/2013 7:12 PM, 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.

Yes. I strongly advise against trying to do this.

> How do I import explicitly from the standard library?

Manipulate sys.path. If you don't know how, either read about sys.path 
(see index) or don't do it.

-- 
Terry Jan Reedy

[toc] | [next] | [standalone]

#41913

On Tuesday, March 26, 2013 3:04:44 AM UTC-4, Terry Reedy wrote:
> On 3/24/2013 7:12 PM, 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.
> 
> 
> 
> Yes. I strongly advise against trying to do this.
> 
> 
> 
> > How do I import explicitly from the standard library?
> 
> 
> 
> Manipulate sys.path. 

This is a common suggestion for working *around* the issue, but it has problems of its own.

In my opinion using sys.path is clunky - you may want to save an restore the value around use especially if the the place you are using it is not at the top level but in some inner less-exposed sub module. And make sure to restore sys.path in the presence of exceptions getting thrown somewhere inside the import. 

It is also a bit of a security nightmare. If something evil gets injected in there what does it effect and how would you know it? sys.path provides a series of directories where and evil masquerading Python program can linger.

And again, I get the impression that for the use case asked about, there isn't much ambiguity. If I am in mypackage.foo and I want to access mypackage.collections I should be able to say something like that without ambiguity or that much inference or directory searching. If mypackage.colletions is not found inside the same directory as mypackage.foo, often I DON'T WANT Python to helpfully go searching around other places for it which sys.path will do. Instead what I probably want is Python to give me an error. 

So again I come to import_relative, http://code.google.com/p/pyimport-relative/.  And again, I wish this package didn't have to exist.

> If you don't know how, either read about sys.path 
> 
> (see index) or don't do it.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

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

#41953

On Tue, Mar 26, 2013 at 08:37:00AM -0700, rocky wrote:
> And again, I get the impression that for the use case asked about, there isn't much ambiguity. If I am in mypackage.foo and I want to access mypackage.collections I should be able to say something like that without ambiguity or that much inference or directory searching. If mypackage.colletions is not found inside the same directory as mypackage.foo, often I DON'T WANT Python to helpfully go searching around other places for it which sys.path will do. Instead what I probably want is Python to give me an error. 
> 
> So again I come to import_relative, http://code.google.com/p/pyimport-relative/.  And again, I wish this package didn't have to exist.

What's wrong with PEP 328 relative imports?

In mypackage.foo, use

    from . import collections

to import mypackage.collections.


This has been part of the language since ~2.5

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

#41958

[Multipart message — attachments visible in raw view] — view raw

On Tue, Mar 26, 2013 at 5:16 PM, Phil Connell <pconnell@gmail.com> wrote:

> On Tue, Mar 26, 2013 at 08:37:00AM -0700, rocky wrote:
> > And again, I get the impression that for the use case asked about, there
> isn't much ambiguity. If I am in mypackage.foo and I want to access
> mypackage.collections I should be able to say something like that without
> ambiguity or that much inference or directory searching. If
> mypackage.colletions is not found inside the same directory as
> mypackage.foo, often I DON'T WANT Python to helpfully go searching around
> other places for it which sys.path will do. Instead what I probably want is
> Python to give me an error.
> >
> > So again I come to import_relative,
> http://code.google.com/p/pyimport-relative/.  And again, I wish this
> package didn't have to exist.
>
> What's wrong with PEP 328 relative imports?
>

They've never worked for me. Some details are mentioned that in the link
above.

If it works for you, great, use it.


> In mypackage.foo, use
>
>     from . import collections
>
> to import mypackage.collections.
>
>
> This has been part of the language since ~2.5
>
>

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

#41960

On Tue, 26 Mar 2013 08:37:00 -0700, rocky wrote:

> And again, I get the impression that for the use case asked about, there
> isn't much ambiguity. If I am in mypackage.foo and I want to access
> mypackage.collections I should be able to say something like that
> without ambiguity or that much inference or directory searching.

And you can: either explicitly say

import mypackage.collections

or use a relative import:

from . import collections

both of which only look inside mypackage.

> If
> mypackage.colletions is not found inside the same directory as
> mypackage.foo, often I DON'T WANT Python to helpfully go searching
> around other places for it which sys.path will do.

With both solutions above, Python will not.


> Instead what I
> probably want is Python to give me an error.
> 
> So again I come to import_relative,
> http://code.google.com/p/pyimport-relative/.  And again, I wish this
> package didn't have to exist.


I'm not convinced it does. I don't understand the problem you are trying 
to solve. "Provide relative imports" is not that problem, because the use-
case you give on the project page does not describe relative imports, as 
they are understood in Python terminology.

The error message you get gives the game away:

ValueError: Attempted relative import in non-package

In a stand-alone module, you can't do a relative import because there is 
no package structure, hence there is nothing to import relative to.

As I don't quite understand your use-case, I'm a shooting in the dark 
here, but it seems to me that you could fix this entire problem by simply 
using a package instead of a directory of stand-alone modules. A mere 
directory of stand-alone modules should be merely loosely coupled, no 
different from any other modules in sys.path. If your modules are tightly 
coupled, they should go in a package.

One thing which would make import manipulations much easier would be if 
import (and __import__) took an explicit search path, as opposed to 
operating on a system-wide global. E.g.

import module using this_path

would be nice.


-- 
Steven

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

#41969

On Tuesday, March 26, 2013 7:06:02 PM UTC-4, Steven D'Aprano wrote:
> On Tue, 26 Mar 2013 08:37:00 -0700, rocky wrote:
> 
> 
> 
> > So again I come to import_relative,
> 
> > http://code.google.com/p/pyimport-relative/.  And again, I wish this
> 
> > package didn't have to exist.
> 
> 
> 
> 
> 
> I'm not convinced it does. 

Sure, the package doesn't have to exist. I'm pretty sure the majority of Python programmers don't use this. So on that sense it doesn't have to exist. 

I meant that I wished I didn't need it in order to support a development style that I use in other programming languages like Ruby, Perl, POSIX shell, or Emacs Lisp, among others. 

There, I can run each file/submodule in a large collection such as the dozens of files in http://code.google.com/p/python3-trepan/ without having to "install" the code. That includes not needing the copying that can go on inside say setup.py to put it in a "build" directory. 

With this I can treat each file/module/submodule in the collection as a main program or not. This helps me isolate and focus on just that part. I can debug it in isolation starting there even though it is a usually submodule of a bigger collection.

> 
> to solve. "Provide relative imports" is not that problem, because the use-
> 
> case you give on the project page does not describe relative imports, as 
> 
> they are understood in Python terminology.

If the information above and on that page isn't clear, then please let's just drop it. 

This is not a new problem. It's been discussed before, I think on this very same newsgroup.

As someone has said, relative imports have been around since 2.5 or so; they've been a disappointment to me ever since then too. 

> 
> 
> 
> The error message you get gives the game away:
> 
> 
> 
> ValueError: Attempted relative import in non-package
> 
> 
> 
> In a stand-alone module, you can't do a relative import because there is 
> 
> no package structure, hence there is nothing to import relative to.

So what pyimport-relative does is provide kind of import statement that makes it irrelevant whether or not this has been run as a main program or not. And yes, I know about Python's '-m' option. 

> 
> 
> 
> As I don't quite understand your use-case, I'm a shooting in the dark 
> 
> here, 


No need to shoot in the dark. If you don't understand the use case, I'm probably not explaining it that well. I'm not asking for help, so let's drop it, lest I get into another long discussion that ultimately leads nowhere.

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

#41914

On Tuesday, March 26, 2013 3:04:44 AM UTC-4, Terry Reedy wrote:
> On 3/24/2013 7:12 PM, 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.
> 
> 
> 
> Yes. I strongly advise against trying to do this.
> 
> 
> 
> > How do I import explicitly from the standard library?
> 
> 
> 
> Manipulate sys.path. 

This is a common suggestion for working *around* the issue, but it has problems of its own.

In my opinion using sys.path is clunky - you may want to save an restore the value around use especially if the the place you are using it is not at the top level but in some inner less-exposed sub module. And make sure to restore sys.path in the presence of exceptions getting thrown somewhere inside the import. 

It is also a bit of a security nightmare. If something evil gets injected in there what does it effect and how would you know it? sys.path provides a series of directories where and evil masquerading Python program can linger.

And again, I get the impression that for the use case asked about, there isn't much ambiguity. If I am in mypackage.foo and I want to access mypackage.collections I should be able to say something like that without ambiguity or that much inference or directory searching. If mypackage.colletions is not found inside the same directory as mypackage.foo, often I DON'T WANT Python to helpfully go searching around other places for it which sys.path will do. Instead what I probably want is Python to give me an error. 

So again I come to import_relative, http://code.google.com/p/pyimport-relative/.  And again, I wish this package didn't have to exist.

> If you don't know how, either read about sys.path 
> 
> (see index) or don't do it.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy

[toc] | [prev] | [standalone]

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

csiph-web