[Python-Dev] question/comment about documentation of relative imports (original) (raw)
Darren Dale dsdale24 at gmail.com
Tue Oct 5 20:17:47 CEST 2010
- Previous message: [Python-Dev] question/comment about documentation of relative imports
- Next message: [Python-Dev] question/comment about documentation of relative imports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Oct 5, 2010 at 1:45 PM, Antoine Pitrou <solipsis at 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
- Previous message: [Python-Dev] question/comment about documentation of relative imports
- Next message: [Python-Dev] question/comment about documentation of relative imports
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]