[Import-SIG] One last try: "virtual packages"

[Stephen Waterbury]

On 07/12/2011 11:03 AM, Barry Warsaw wrote:
> It's a very interesting idea that is worth exploring.  A few
> things come to mind:
>
> - Under this scheme it's possible for names in a module to
>   "suddenly" appear.  E.g. I could install packages that extend
>   existing top level modules like `time` or `string`.  This
>   might be a good thing in that it gives 3rd party folks a more
>   natural place to add things, but it could also open up a
>   land-grab type collision if lots of people want to publish
>   their packages as subpackage extensions to existing modules.

Names can suddenly appear only if installed and imported,
so that doesn't seem too scary to me.  As to the land-grab
type collision, there are similar dangers today -- we're all
consenting adults here ... ;)

> - It's unfortunate that this will be more difficult to back
>   port to Python 2.

To me the elegance seems worth the price (assuming no big gotchas
that haven't been noticed yet) ... OTOH, I'm not the one doing
the back porting ... "for the man who doesn't have to do it,
nothing is impossible ..." ;)

> - It sounds like it will be more difficult to have a single
>   code base that supports Python 2, Python3<= 3.2, and Python
>   3.3.  This is because __init__.py is required in the first two,
>   but does the wrong thing (I think ;) in a post-PEP 382 Python
>   3.3.  Adding a .pyp file that's ignored in anything that
>   doesn't support PEP 382 would make it easier to support
>   multiple Pythons.

That's a consideration, but it seems a fairly simple script could
add the __init__.py files to create a version of the codebase for
the Python versions that require them.  I might be
over-simplifying, though.

> - This should make vendor packaging tools happy because it does
>   seem to eliminate file collisions (duplicate directories don't
>   matter).

Right.

> Let's see the PEP!

The peanut gallery is riveted ... :)

Steve