On Tue, 30 Sep 2008 23:32:14 +0200, Josselin Mouette
[snip]
The marketing name does not have to be the same of the name of the module you import. The situation where they differ is even quite common.
You can also argue for separating the name from the API version, like the soname of a library, and I’ll agree, but in the end it is very similar.
Do you think this is practical for non-trivial libraries? For any library which has more than one API, the possibility exists for one API to change incompatibly and the other to remain compatible. With larger libraries, the value of changing the module name because one (or some other small fraction of the whole) API changed incompatibly decreases as compared to the cost of updating all software which uses the library to use the new name (much of which may well be unaffected by the incompatible change). I am a huge fan of backward compatibility. You may not find a bigger one (at least in the Python community). I can't understand how this approach can be made feasible though. Should the next release of Twisted include a Python packaged named "twisted2" instead of "twisted"? And the one after that "twisted3"? There are thousands of APIs in Twisted, and we do change them incompatibly (after giving notice programmatically for no less than 12 months). Should we instead give up on this and make all users of Twisted update their code to reflect the new name with each release? Jean-Paul