[Python-ideas] improve compatibility

[Nick Coghlan]

On 29 November 2014 at 15:07, Andrew Barnert
<abarnert at yahoo.com.dmarc.invalid> wrote:
> On Nov 28, 2014, at 8:29, Liam Marsh <liam.marsh.home at gmail.com> wrote:
>
>> hello,
>> the problem is that even with extreme precaution, it is impossible to keep ALL modules compatible from a version to another.
>
> Do you have a specific library or app that you've had a problem with? There were a handful of modules that had a problem with the 3.2 to 3.3 conversion, but every one I saw was caused by language and implementation changes, not stdlib changes. I don't think I've seen anything that works with 3.3 but not 3.4. I'm sure it's not impossible for such a thing to happen, but it would be helpful to have at least one real-life example.

The desire for doing selective upgrades on a stable base is actually a
pretty common one (e.g. using modern unittest features on Python 2.6
or 2.7). The hard part is figuring out a way to provide those
selective upgrades cost effectively. (In the context of unpaid
development, the costs are measured in contributor time)

>> what I want to ask is this:
>> -some "packs" which can, like py-compile, generate .pyc files, but using "old" versions of the default library, and of __builtins__.
>
> But how would this work? The same changes that broke a handful of third-party modules between 3.2 and 3.3 probably also mean that the 3.2 stdlib wouldn't work in 3.3 without minor changes. And as for builtins, most of those are exposing internals of the implementation, so trying to make the 3.2 builtins work with 3.3 would take a lot more work than just building the 3.2 code against 3.3.

The feature Liam is looking for effectively already exists, in the
form of updated standard library modules that have been backported to
earlier versions via PyPI. There's a (likely incomplete) list at
https://wiki.python.org/moin/Python2orPython3#Supporting_Python_2_and_Python_3_in_a_common_code_base.

This tackles the problem in the opposite direction, by ensuring
particular modules remain compatible with older versions, rather than
only running on the latest release. One of our reasons for making pip
more readily available to Python 2 users in Python 2.7.9 is to make
those modules easier to access (together with Python 3 migration tools
like six, modernize, future, and caniusepython3).

Cheers,
Nick.

P.S. While some of those backports are maintained directly by core
developers, the PSF license actually allows anyone that wants to (and
has the necessary time available) to backport modules. A number of the
backports originated in users wanting particular features on earlier
versions for their own use, and deciding to make their backport
generally available, rather than keeping it to themselves.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia