Dne 20.8.2009 21:52, Brett Cannon napsal(a):

2009/8/20 Jan Matejek :

...

Dne 20.8.2009 11:47, Matthias Klose napsal(a):

...

On 14.08.2009 10:02, Tarek Ziadé wrote:

...

On Thu, Aug 13, 2009 at 9:22 PM, Brett Cannon wrote:

...

On Thu, Aug 13, 2009 at 11:23, Jan Matejek wrote:

Among the proposals you have detailed, the sharedir way seems like the most simple/interesting one (depending on you answer to Brett's question )

The approach of splitting the installation into two different locations seems to be wrong, it changes the semantics for imports of python packages which are not installed in the same location. Simplest counter example is the use of relative imports, which will fail if the imported module/extension is not found in the same paths.

isn't using relative imports outside packages a bad practice?

You actually can't do relative imports outside of packages; Python won't allow it.

all the better

...

I'm not proposing to split installation of single package. I'm proposing having two different default install locations, based on package type (platform dependent/independent), not on file type. Package is pure (platform independent) as long as -all- of its files are pure.

I have seen one problem so far: wxGTK's python part installs a .pth file along with its purelib part, that supposedly points to its platlib package. That of course breaks when purelib != platlib.

But aren't you suggesting that something like wxGTK that is impure not be installed in two separate locations, meaning the .pth file will work fine?

Situation with wxGTK is such that it contains two separate packages - one is pure, but installs the .pth. Other is impure and apparently needs the .pth to be enabled. That's what i consider a bug, because it relies on all packages being installed into the same location.

...

So far i would consider this a bug in wxGTK, or rather relying on behavior that is not well defined. But i admit that i'm not sure.

I would argue it is well defined. When you install a package all of its files end up in a single directory, letting you make assumptions that a .pth file will be relative to all files you have installed.

...

...

Other languages like Perl or Java don't have relative imports, or they map all components on the "path" into one logical path so you don't have this kind of problem.

and that's probably why perl approach would fail miserably in python ;) unless we implemented mapping to one path. Hopefully, we probably don't need to do it.

Not sure what you mean by "mapping to one path". Are you saying Perl basically treats all directories on its path as if it was one big directory? If so Python already does that with sys.path (but with a defined order). But as soon as you end up in a package that goes away as __path__ takes over (although that can be changed and is the reason pkgutil exists).

-Brett

As you're saying. Relative imports break the abstraction. In order to implement the "perl approach", i.e. splitting by pure/impure files instead of packages, we would need relative imports to support this. But this is all just theoretical. As there doesn't seem to be any compelling argument to go this way, let's stick with what works now. regards m.