Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: import in Python3.3

Reply
Thread Tools

Re: import in Python3.3

 
 
Terry Reedy
Guest
Posts: n/a
 
      03-26-2013
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

 
Reply With Quote
 
 
 
 
rocky
Guest
Posts: n/a
 
      03-26-2013
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


 
Reply With Quote
 
 
 
 
rocky
Guest
Posts: n/a
 
      03-26-2013
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


 
Reply With Quote
 
Phil Connell
Guest
Posts: n/a
 
      03-26-2013
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

 
Reply With Quote
 
Rocky Bernstein
Guest
Posts: n/a
 
      03-26-2013
On Tue, Mar 26, 2013 at 5:16 PM, Phil Connell <(E-Mail Removed)> 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
>
>


 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      03-26-2013
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
 
Reply With Quote
 
rocky
Guest
Posts: n/a
 
      03-27-2013
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 verysame 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
to use import java.lang.* or import java.lang.Math or none at all? JPractitioner Java 13 02-24-2006 08:48 PM
XML Schema question - does "import" import elements? Vitali Gontsharuk XML 2 08-25-2005 07:33 PM
IMPORT STATIC; Why is "import static" file scope? Why not class scope? Paul Opal Java 12 10-10-2004 11:01 PM
GTK import doesn't import first time Dennis Python 2 08-18-2003 10:00 PM
import/from import question Artur M. Piwko Python 1 07-02-2003 07:04 PM



Advertisments