> I guess i think there is a case to be made for relative imports, and > it becomes apparent as an enterprise grows. > > Increasingly at Zope corp we are mixing and matching packages to > deliver applications to a customer. This is very encouraging, because > it means we are actually getting reuse out of the packages. > > Currently, we can just plop the things in place, and use them. > Without relative imports, we would have to be editing the imports in > the packages in each place we use it. This would increase the burden > of using the packages and even more of feeding back actual fixes - > which we then have to distinguish from what i would see as gratuitous > changes to edit import names. I know this line of reasoning fairly well. You are taking 3rd party packages (or perhaps internally developed packages) and copy them to a *different place in the package namespace tree*. Right? But why do you have to give those packages a different full name? That's the question that I've never seen answered adequately. > If you would grant there's use to avoiding those edits, and so there's > use to having relative imports, then you might see a reason to solve > the problems where the names in a package conflict with those along > the load path. Otherwise, if there's only absolute imports, there's > no ambiguity to resolve. I'd say there's a legitimate need for > relative imports, and we need some explicit gesture to disambiguate > between a relative and absolute import, one way or the other. I think that moving packages around in the package namespace is a bad idea. But maybe you can give me an answer to the question above to convince me. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4