>>>>> "MAL" == M -A Lemburg <mal@lemburg.com> writes: MAL> To provide more flexibility to the third-party tools in such a MAL> situation, I think it would be worthwhile moving the MAL> site-packages/ entry in sys.path in front of the lib/python2.0/ MAL> entry. MAL> That way a third party tool can override the standard lib's MAL> package or module or take appropriate action to reintegrate the MAL> standard lib's package namespace into an extended one. MAL> What do you think ? I think it is a bad idea to encourage third party tools to override the standard library. We call it the standard library for a reason! It invites confusion and headaches to read a bit of code that says "import pickle" and have its meaning depend on what oddball packages someone has installed on the system. Good bye, portability! If you want to use a third-party package that provides the same interface as a standard library, it seems much clearn to say so explicitly. I would agree that there is an interesting design problem here. I think the problem is support interfaces, where an interface allows me to write code that can run with any implementation of that interface. I don't think hacking sys.path is a good solution. Jeremy
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