On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > Le mardi 05 octobre 2010 à 13:28 -0400, Darren Dale a écrit : >> >> >> >> 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 > > That use case requires that the third-party package, not your package, > use relative imports. I don't think you can require other projects to > follow your coding style recommendations (unless of course you maintain > both).
I'm not talking about requiring other projects to follow my coding style. > I'm not sure I understand the issue. The issue is implementing a PEP with nice support for relative imports, and then documenting that it should never be used. 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