Guido van Rossum wrote: > On 9/21/06, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote: >> I think it goes further than that -- each module should >> (potentially) have its own unique view of the module >> namespace, defined at the time the module is installed, >> that can't be disturbed by anything that any other module >> does. > > Well, maybe. But there's also the requirement that if packages A and B > both import C, they should get the same C. Having multiple versions of > the same package loaded simultaneously sounds like a recipe for > disaster. I have exactly this scenario in my current codebase for a server. It was absolutely necessary for me to update a module in Twisted because all other solutions I could come up with were less desirable. Either I send my patch upstream and wait (can't wait), or I fork out another version and place it at the top of sys.path (this seems ok). Except an even better solution is to maintain my own subset of Twisted, because I am localized to a particularly small corner of the codebase. I can continue to use upstream updates to the rest of Twisted without any fussing about merging changes and so forth. And if Twisted was allowed to decide how it saw its own world, then I would have to go back to maintaining my own complete branch. While I don't strictly need to be able to do this, I wanted to at least raise my hand and say, "I abuse this facet of the current import mechanism." -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu
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