A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2001-October/017748.html below:

[Python-Dev] Backward compatibility

[Python-Dev] Backward compatibilitySkip Montanaro skip@pobox.com (Skip Montanaro)
Thu, 4 Oct 2001 21:12:21 -0500
    Aahz> As one of the frequent ranters about compatibility issues, I
    Aahz> thoroughly endorse this approach WRT "batteries included" as long
    Aahz> as the APIs stay the same.

I don't think APIs have much to do with this particular item.  No API
changed in xmlrpclib.py, but the code became incompatible with pre-2.0
releases.  I checked in a change to xmlrpclib.py that used "import foo as
bar".  The question I raised implicitly by making an incompatible change to
xmlrpclib.py was "is it okay to use all the features of the current release
in a core module?".  Tim's answer was a qualified "yes", the exception being
for modules maintained by other authors.  In PythonLabs view it's ultimately
Fredrik's responsibility to maintain backward compatibility if he so
chooses.  I realized it about 30 seconds after I checked in the change,
which was why I mentioned it.  I didn't know if he maintains a separate copy
for backwards compatible releases or relies on the code now in the Python
CVS repository.  In retrospect, I should probably have sent him a note
instead of checking in the change.

Skip




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