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