A while ago I created a backport of statistics to Python 2.6 to 3.3. [1] It worked pretty and required just a few modifications to the code. I'd like to add most modifications to 3.4 to simplify backporting.

The modifications are:

* from __future__ import division
* replace super() with super(MySuperClass, self)
* changes to doc tests because Python 2 has slightly different represenstations (<type 'float'> / <class'float'>, longer float repr)
* "import collections" -> "from collections import Counter" so I can simply add a Counter class for 2.6
* "import math" -> "from math import isfinite" so it's easier to add a isfinite() function for 2.x

The patch does neither remove "raise ... from None" nor does it add a 2.x isfinite or range = xrange. The backport still needs some patches but I can keep the amount of changes rather small.

[1] https://bitbucket.org/tiran/backports.statistics

-1.

First, I don't think stdlib modules should be forced to use old conventions and give up on new features just because of backports (the import changes are fine obviously).

Second, it's putting unreasonable constraints on CPython developers to know which modules should be compatible with which version and which features that requires to ignore (Python 2.6 is not even in maintenance anymore!)  This is the onus of the backporter (and you have done it already, anyway).

Third, it's also a little late for this given that we're now in beta.

Python's stdlib contains other modules that contain code for older versions of Python. The platform module even contains lines like "os.devnull was added in Python 2.4, so emulate it for earlier". asyncio has backward compatibility code, too. The only old syntax I'd like to add is the super() thing in the test module. They are just tests...

The modified imports and doc test adjustments like

-    >>> mean([1, 2, 3, 4, 4])
-    2.8
+    >>> mean([1, 2, 3, 4, 4]) == 2.8
+    True

would greatly help, though.

This is a tricky one.  I can see the arguments either way, but it just feels wrong to have future imports in stdlib code.

I personally don't see anything wrong with the import and doctest changes, though.  Sure, someone may come along later and unknowingly break something for your backport, but it isn't likely and IMO it's no big deal if it happens, you can just fix it when your tests fail.  I also don't mind the super call change personally, but that is much more likely to get changed by someone later, since I'm sure other people find it uglier than I do :)

Platform kind of operates under its own rules.  I suppose asyncio does as well :)

If you started at 2.7 you would need less changes.

"Python's stdlib contains other modules that contain code for older versions of Python. The platform module even contains lines like "os.devnull was added in Python 2.4, so emulate it for earlier"."

I never understood why the platform module should be backport compatible. Marc Andre Lemburg wrote that it is shipped externally. I don't understand the purpose of having a third party platform module since the module is part of the stdlib.

> I'd like to add most modifications to 3.4 to simplify backporting.

I would prefer to not touch Python 3.4 backport just to simplify backporting. For example, I don't expect "from __future__ import division" in new Python 3.4 modules, but only on old modules.

If the Python 3.4 evolves, you can use tools like meld to compare your backport and the latest version, and merge manually new changes. Or read Mercurial history of the Python 3.4 module to get patches.

For example, I maintain the faulthandler like that. I manually merge changes when I fix an issue in the CPython version. The version on PyPI is different: it uses SIGALRM instead of a thread, use PyInt_xxx() functions on Python 2, etc.

Do we expect many changes in the statistics modules?

FWIW, I sympathize with Christian's goal here, since I'm gonna have to backport pathlib too :-)

However, I think the following changes do make the docstrings less readable:

-    >>> mean([1, 2, 3, 4, 4])
-    2.8
+    >>> mean([1, 2, 3, 4, 4]) == 2.8
+    True

> However, I think the following changes do make the docstrings less readable:

Doctests are not reliable. IMO it's better to use unittest with testcases. unittest is easier to maintain, work with Python 2 and 3, and usually provide more useful reports on error.

unittest has more features like functions to skip a test on a specific platform.

As Victor says, I'm not keen on those examples in the stdlib that do this, I'd rather get rid of all of them.

And yes, doctests are only useful if they are written in the simplest possible way.  Otherwise unittest style tests should be preferred.

I too prefer to move in the direction of less back-compatibility constraint rather than more.

If I had written the module, I would prefer the altered doctest as being less fragile and representation dependent. For 1 or 2 objects, I prefer the from form anyway. So yes to those from me.

I am curious what Steven thinks, should he care to opine.