On Tue, Oct 5, 2010 at 12:43 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Tue, 05 Oct 2010 17:18:18 +0100 > Michael Foord <fuzzy...@voidspace.org.uk> wrote: >> > >> > Generally I'm +0 on relative imports as a whole. >> >> As the OP pointed out, for code that may be *included* in other projects >> there is no other choice. This is often useful for packages shared >> between one or two projects that nonetheless don't warrant separate >> distribution. > > You can put several packages in a single distribution.
Thats not the point though. Due to compatibility issues, maybe I don't want to expose the code at the top level. Maybe the foo package is distributed elsewhere as a top-level package, but I need to use an older version due to compatibility problems. I certainly don't want to risk overwriting a pre-existing installation of foo with my required version of foo. This is not a hypothetical, we once had exactly this problem when we distributed an old version of enthought.traits with matplotlib (even though we checked for pre-existing installations, crufty build/ directories containing the out-of-date traits package were overwriting existing installations). Darren _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
