On Mar 15, 2010, at 08:47 PM, Jonathan Wiltshire wrote: >It occurs to me that there's very little guarantee of a stable API in >Python modules - less so in C modules, because upstream tends to be more >aware that this is a library, but in pure Python modules. There is nothing other than convention to prevent this from happening in pure Python modules. For those that are distributed in the standard library, I think you can be more comfortable with stable APIs. We take great pains not to change APIs between patch releases, and have policies for backward compatibility and deprecations between major releases of Python. This is not to say that we don't break things accidentally, but it should be considered a bug when it happens counter to Python project policy. >In lib* libraries, we (usually) have SONAMEs which provide some kind of >contract between the .so and the consuming application. Is there an >equivalent practice in pure Python modules that is implemented widely enough >to be useful? For third party libraries, well, to each its own. ;) You /hope/ that upstreams would use common practice of bumping major version numbers when they do this, and the best you can do is use packaging hints to decide which versions of the package you want. This is some support for this in tools like buildout, but that probably doesn't help you much. In Python 2.7 and 3.2, things will get better via the suite of distutils PEPs being adopted, but only in that you should at least be able to declare and manage versions in a more principled way. It will still be up to the upstream maintainers to do the right thing though. >The question came about because the upstream author of RedNotebook ships a >number of convenience copies, sometimes heavily modified, because he is >nervous about APIs changing suddenly and wasting his work. It's likely that >there will be more of these in the near future. Is there anything with which >I can reassure him and reduce the amount of duplicated code in this >application? What has he actually been burned by? Third party Libraries, standard libraries? I think in general, this is not a good practice and can make things more difficult in the long run. But it helps to know specifics. -Barry
Attachment:
signature.asc
Description: PGP signature