On Sat, 2004-04-03 at 13:24, Bernhard Herzog wrote: > I don't think this is a good description of the actual problem. The > problem is that the modules in the package shadow global ones and > there's no easy way to bypass the local package. FWIW, though, I don't > recall ever running into a problem with that. It happens, and it makes for tricky choices. I know to stay away from internal modules like re and email, but as the standard library gets fatter, there's more chance of collision. The only remedy will be to rename an internal module when I find that I suddenly want to use some new standard module. There should be more independence. If all import paths were absolute, then I wouldn't have this problem, and in fact, that's the rule my own code tries to adhere to. See the email package which uses absolute imports internally. I know others have use cases for relative imports, but I've never quite seen the need. Ideally, IMO, all imports would be absolute. If we have to throw a bone to relative import proponents in order to get to absolute imports by default, so be it. -Barry
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