[issue19763] Make it easier to backport statistics to 2.7

Changes by Christian Heimes : -- resolution: -> wont fix stage: patch review -> resolved status: open -> closed ___ Python tracker ___ __

[issue19763] Make it easier to backport statistics to 2.7

Terry J. Reedy added the comment: 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

[issue19763] Make it easier to backport statistics to 2.7

Georg Brandl added the comment: 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. -- __

[issue19763] Make it easier to backport statistics to 2.7

STINNER Victor added the comment: > 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

[issue19763] Make it easier to backport statistics to 2.7

Antoine Pitrou added the comment: 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

[issue19763] Make it easier to backport statistics to 2.7

STINNER Victor added the comment: > 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.

[issue19763] Make it easier to backport statistics to 2.7

STINNER Victor added the comment: "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

[issue19763] Make it easier to backport statistics to 2.7

Antoine Pitrou added the comment: If you started at 2.7 you would need less changes. -- nosy: +pitrou, stevenjd ___ Python tracker ___ ___

[issue19763] Make it easier to backport statistics to 2.7

R. David Murray added the comment: 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 br

[issue19763] Make it easier to backport statistics to 2.7

Christian Heimes added the comment: 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 sy

[issue19763] Make it easier to backport statistics to 2.7

Georg Brandl added the comment: -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 mod

[issue19763] Make it easier to backport statistics to 2.7

New submission from Christian Heimes: 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