Chris Barker wrote: > This really doesn't work well for complex packages. I was quite involved > with the debate about versioning for wxPython (and helped drive it > happening) and that was what I originally proposed. The problem is that > you have a whole pile of modules and libs and user code that all imports > the package. There are a LOT of "import wx" lines in the wxPython > library, and a whole bunch more in a sizable wxPython app. As you > upgrade, every one of those would have to be changed to > > import wx_x_y_z as wx Not at all. Import wx_x_y_z could do sys.modules["wx"] = wx_x_y_z and then all references to import wx would automatically resolve to the version that was imported first (or last, depending on your implementation strategy). > This was not considered a reasonable solution. Among other things, it's > really nice to be able to make a small change in just one file, and be > able to test your app against a new version. Even if the package is not prepared to register itself under a different name also, this one file could modify sys.modules. Or you can have a wx.py that reads from wx_x_y_z import * Then, wx.py would be that single file. > The versioning system that wxPython now has is quite nice, and seems to > fit most people's needs well. Very good! Then I don't see a need to change anything in Python. > This is quite true, and why I haven't bothered with a PEP, but maybe > I've got the thinking backwards, we need the PEP to get the "important" > people thinking about it. I don't think a PEP is needed - Python already appears to have everything you need to come up with your own versioning rules. Regards, Martin
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