[Python-Dev] Import redesign (was: Python 1.6 status)

[James C. Ahlstrom]

Guido van Rossum wrote:

> I think the standard format should be a subclass of zip or jar (which
> is itself a subclass of zip).  We have already written (at CNRI, as
> yet unreleased) the necessary Python tools to manipulate zip archives;
> moreover 3rd party tools are abundantly available, both on Unix and on
> Windows (as well as in Java).  Zip files also lend themselves to
> self-extracting archives and similar things, because the file index is
> at the end, so I think that Greg & Gordon should be happy.

Think about multiple packages in multiple zip files.  The zip files
store file directories.  That means we would need a sys.zippath to
search the zip files.  I don't want another PYTHONPATH phenomenon.

Greg Stein and I once discussed this (and Gordon I think).  They
argued that the directories should be flattened.  That is, think of
all directories which can be reached on PYTHONPATH.  Throw
away all initial paths.  The resultant archive has *.pyc at the top
level,
as well as package directories only.  The search path is "." in every
archive file.  No directory information is stored, only module names,
some with dots.
 
> > I don't like sys.path at all.  It is currently part of the problem.
> 
> Eh?  That's the first thing I hear something bad about it.  Maybe
> that's because you live on Windows -- on Unix, search paths are
> ubiquitous.

On windows, just print sys.path.  It is junk.  A commercial
distribution has to "just work", and it fails if a second installation
(by someone else) changes PYTHONPATH to suit their app.  I am trying
to get to "just works", no excuses, no complications.
 
> > I suggest that archive files MUST be put into a known directory.
> 
> Why?  Maybe this works on Windows; on Unix this is asking for trouble
> because it prevents users from augmenting the installation provided by
> the sysadmin.  Even on newer Windows versions, users without admin
> perms may not be allowed to add files to that privileged directory.

It works on Windows because programs install themselves in their own
subdirectories, and can put files there instead of /windows/system32.
This holds true for Windows 2000 also.  A Unix-style installation
to /windows/system32 would (may?) require "administrator" privilege.

On Unix you are right.  I didn't think of that because I am the Unix
sysadmin here, so I can put things where I want.  The Windows
solution doesn't fit with Unix, because executables go in a ./bin
directory and putting library files there is a no-no.  Hmmmm...
This needs more thought.  Anyone else have ideas??

> > We should also have the ability to append archive files to the
> > executable or a shared library assuming the OS allows this
>
> OK for the executable.  I'm not sure what the point is of appending an
> archive to the shared library?  Anyway, does it matter (on Windows) if
> you add it to python16.dll or to python.exe?

The point of using python16.dll is to append the Python library to
it, and append to python.exe (or use files) for everything else.
That way, the 1.6 interpreter is linked to the 1.6 Lib, upgrading
to 1.7 means replacing only one file, and there is no wasted storage
in multiple Lib's.  I am thinking of multiple Python programs in
different directories.

But maybe you are right.  On Windows, if python.exe can be put in
/windows/system32 then it really doesn't matter.

> OK, OK.  I think most zip tools have a way to turn off the
> compression.  (Anyway, it's a matter of more I/O time vs. more CPU
> time; hardare for both is getting better faster than we can tweak the
> code :-)

Well, if Python now has its own compression that is built
in and comes with it, then that is different.  Maybe compression
is OK.
 
> Well, the question is really if we want flexibility or archive files.
> I care more about the flexibility.  If we get a clear vote for archive
> files, I see no problem with implementing that first.

I don't like flexibility, I like standardization and simplicity.
Flexibility just encourages users to do the wrong thing.

Everyone vote please.  I don't have a solid feeling about
what people want, only what they don't like.
 
> > If the Python library is available as an archive, I think
> > startup will be greatly improved anyway.
> 
> Really?  I know about all the system calls it makes, but I don't
> really see much of a delay -- I have a prompt in well under 0.1
> second.

So do I.  I guess I was just echoing someone else's complaint.

JimA