Consider dropping Python 2.6 (and maybe 3.3) support/CI-testing

[gojomo]

Per the 'Status of Python branches' section of the Python Developer's Guide, Python 2.6 reached end-of-life just over 3 years ago (2013-10-29). Having not even received security-related bugfixes, those running it are taking a risk. And, moving to 2.7 isn't that hard. So perhaps, the project should remove 2.6 from the list of 'tested' Python versions.

Python 3.3 will reach end-of-life in under a year (2017-09-29); it's currently receiving only security fixes. But its adoption was never as large as the 2.x series, and the kinds of novelty-friendly projects that adopted it are also especially likely to have continued moving to 3.4/3.5. Removing support for 3.3 might affect zero gensim users.

Trimming the testing list would eliminate occasional surprise failures when a feature missing from 2.6/3.3 is inadvertently used. It would also make the rare-intermittent-failures (remaining in a few of our tests) less likely to cause distraction during unrelated work. (Of course those should be further fixed/minimized, but running excess tests compounds the costs they impose on other contributors.)

Finally, even with Travis-CI's parallelism, fewer tests will usually mean full results from any full run can be available sooner.

[piskvorky]

2.6: Definitely not; we still have clients that use 2.6.

3.3: Possibly. Probably a good idea to ask the community first, since we don't use py3 ourselves.

[gojomo]

I use Python 3 for new projects whenever I have the choice!

Even for deployed/legacy systems still using Python 2.6, perhaps they can just stick with older gensim releases? (If they're actually deploying fresh gensim features there's a good case that they should probably be using a security-patch-supported CPython, too.)

[gojomo]

How about before a gensim 1.0.0 – a threshold where users expect changes in API/support – we prune some supported versions?

I'd suggest dropping Python 3.3 and 3.4 for sure – Python 3 users are more likely to cluster at the latest versions.

I think dropping Py2.6 support for 1.0.0+ would be a defensible choice even if we know of still-extant Py2.6 deployments. People needing newer features should be moving off a Python that's had no security fixes in 3+ years – and in the rare case where some showstopper bug is found that affects a deployment-on-2.6, and upgrading to Py2.7 is not an option, a minimal backported fix, to a 0.X.Y patch release, is an appropriate way to support such legacy deployments.

Even if Py2.6 isn't dropped, a "1.0" would still be a good time to announce a future date when support for it will end, to nudge users to upgrade their practices sooner, and decrease any surprise whenever support is dropped.

[piskvorky]

Agreed on dropping Python 3.3 and 3.4. The move to 1.0.0 makes this the perfect opportunity :)

2.6 is a little trickier. I've thought about this again and in the end I think you're right. Old deployments can stay with old gensim versions (pre-1.0.0). With possible backport fixes where critical.

[piskvorky]

@tmylk what does dropping these versions mean for the codebase, concretely?

How much refactoring to upgrade gensim to 2.7 code patterns (comprehensions, set literals, ?).

[gojomo]

I wouldn't think any up-front refactoring work is necessary: simply dropping the commitment to 2.6, so that as new work is done, 2.7+ features will be used when natural (and not be rolled-back when they fail tests).

As a way to take the temperature of gensim users on such a change, the @gensim_py Twitter account could tweet a poll along the lines of:

As a gensim user, is it important to you that future gensim releases support these older Python versions?
[ ] Python 2.6
[ ] Python 3.3
[ ] Python 3.4
[ ] No – OK with 2.7 & 3.5+

[tmylk]

Dropped in #1145