Guido van Rossum writes:
I think it's worth looking again into the issue of where package-specific shared libs should come from when the package itself is loaded from an archive.
As well as in the existing case of packages with both Python and C components. It simply doesn't make sense for a package containing primarily cross-platform files to be installed in platform-specific locations simply because the infrastructure doesn't understand the split. This is *not* an issue of disk space; I expect packages will appear which include data as well as code; these packages should be able to locate their associate data files using __path__ (or something similar). This makes a lot of sense for packages that perform character-set recoding and the like, where a large number of translation files may be carried along as part of the package.
I claim that it *is* an issue of disk space. Having the installation of a particular package spread out over two places is inconvenient from a management point of view, and sharing one of those places between different installations (for different platforms) of the same package just makes it a lot worse.
Note that your example hinges on "a large number of translation files". That reeks of a disk space argument! (If you were thinking of network bandwidth or download time, there are other solutions that don't affect the install locations.)
--Guido van Rossum (home page: http://www.python.org/~guido/)