[Python-Dev] python package

[Guido van Rossum]

> > I think you could get a long way with minor changes along the lines of
> > making site-packages a package itself.
> 
> This wouldn't work since in that case you'd have the problem
> of having to fix class names in e.g. pickles for objects
> which you don't know anything about. We do know about objects
> in the Python standard lib, so we could take care to have mechanisms
> like pickle deal with them properly.

IOW you're suggesting we do a near-infinite amount of work to the core
just so that others can be sloppy in their choice of names for their
modules.  Bah.

> I believe that the more Python grows (not only the core,
> but the complete set of available modules and packages in
> the Python universe), the less likely we are going to
> hit a problem.

I would say, OK, so it will go away by itself, but I guess you made a
typo there, and really meant "the more likely...". :-)

But making the core go away doesn't reduce the problem enough: the
more likely problem is two 3rd parties unaware of each other each
picking the same name.

> > I'm rejecting the proposal of a single top-level package named "python".
> 
> You've written that before, but you still haven't given any
> explanation of why a single package would be worse than a
> multi-level hierarchy of modules (e.g. grouped by application
> space).

Because a single package doesn't have any other benefits besides
getting out of the way from 3rd party developers.

At least a proper hierarchy would have the other benefits of grouping.
(But better make it a shallow hierarchy!  remember "Flat is better
than nested.")

> I think that simply moving to one package would cause less
> breakage and make the whole transition process much easier
> than having to tweak code into using some complicated
> multi-package structure.

Given that you now want us to add special counter-measure to pickle, I
doubt that very much.

> FWIW, I've been through all this with the mx packages
> and using a single new package caused the least amount
> of work. Even better: it turned out to be easy to provide
> backwards compatibility code so that applications still
> using the old layout continue to run, but start using the
> new structure in their pickles.

So it's no big deal for 3rd party developers to do what they should do
to deal with this problem.  Good to hear.  Given that when we change
the standard library, *every* Python user (and developer) is affected,
I prefer the status quo.

> No need to get heated, though. I just thought that it would
> be a good time to start thinking about this option again.

And this would be a good time to end this thread. :-)

--Guido van Rossum (home page: http://www.python.org/~guido/)