[Scikit-learn-general] Dropping Python 2.6 compatibility

[Gael Varoquaux]

Happy new year everybody,

As a new year resolution, I suggest that we drop Python 2.6
compatibility.

For an argumentation in this favor, see
http://www.snarky.ca/stop-using-python-2-6 (I don't buy everything there,
but the core idea is there).

For us, this will mean more usage of context managers, which is good.

The down side is that many clusters run RedHat variant that are still
under 2.6 (Duh!). The question is: are people using the stock Python on
the clusters, or something else.

Opinions please?

Gaël

------------------------------------------------------------------------------

[tom]

For what it’s worth, pandas is dropping 3.3 in our next release (0.18 maybe end of this month). We’re possibly dropping 2.6 as well, but it might get one more release.

-Tom

Post by Gael Varoquaux
Happy new year everybody,
As a new year resolution, I suggest that we drop Python 2.6
compatibility.
For an argumentation in this favor, see
http://www.snarky.ca/stop-using-python-2-6 (I don't buy everything there,
but the core idea is there).
For us, this will mean more usage of context managers, which is good.
The down side is that many clusters run RedHat variant that are still
under 2.6 (Duh!). The question is: are people using the stock Python on
the clusters, or something else.
Opinions please?
Gaël
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

------------------------------------------------------------------------------

[Dale Smith]

My own opinion, after reading the link in the original message in this thread, is to drop Python 2.6 support.

Perhaps Python Weekly and LWN will report on this to increase visibility.

As a follow-up, I'd like to point out

http://www.snarky.ca/why-python-3-exists

Dale Smith, Ph.D.
Data Scientist
​


d. 404.495.7220 x 4008   f. 404.795.7221
Nexidia Corporate | 3565 Piedmont Road, Building Two, Suite 400 | Atlanta, GA 30305

    


-----Original Message-----
From: tom [mailto:***@gmail.com]
Sent: Monday, January 04, 2016 8:38 AM
To: scikit-learn-***@lists.sourceforge.net
Subject: Re: [Scikit-learn-general] Dropping Python 2.6 compatibility

For what it’s worth, pandas is dropping 3.3 in our next release (0.18 maybe end of this month). We’re possibly dropping 2.6 as well, but it might get one more release.

-Tom

Post by Gael Varoquaux
Happy new year everybody,
As a new year resolution, I suggest that we drop Python 2.6
compatibility.
For an argumentation in this favor, see
http://www.snarky.ca/stop-using-python-2-6 (I don't buy everything
there, but the core idea is there).
For us, this will mean more usage of context managers, which is good.
The down side is that many clusters run RedHat variant that are still
under 2.6 (Duh!). The question is: are people using the stock Python
on the clusters, or something else.
Opinions please?
Gaël
----------------------------------------------------------------------
-------- _______________________________________________
Scikit-learn-general mailing list
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
Scikit-learn-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
------------------------------------------------------------------------------

[Andreas Mueller]

Happy new year!

I think it would be cool to hear from matplotlib what their experience was.
I'm not sure I'm for dropping 2.6 for the sake of dropping 2.6.
What would we actually gain?
There are two fixes in sklearn/utils/fixes.py that we could remove, I think.

Also: what does dropping 2.6 mean? Writing in the docs that we don't
support it any more?
Shutting down the continuous integration? Removing the fixes?

If we remove the fixes, we force users to upgrade, with little benefit
to us, right?

Cheers,
Andy

ps: I'm not against dropping 2.6, I just want a discussion ;)

Post by Gael Varoquaux
Happy new year everybody,
As a new year resolution, I suggest that we drop Python 2.6
compatibility.
For an argumentation in this favor, see
http://www.snarky.ca/stop-using-python-2-6 (I don't buy everything there,
but the core idea is there).
For us, this will mean more usage of context managers, which is good.
The down side is that many clusters run RedHat variant that are still
under 2.6 (Duh!). The question is: are people using the stock Python on
the clusters, or something else.
Opinions please?
Gaël
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

------------------------------------------------------------------------------

[Gael Varoquaux]

Post by Andreas Mueller
I'm not sure I'm for dropping 2.6 for the sake of dropping 2.6.

I agree. I find the attitude of the post that I mentionned a bit
annoying: dropping support for the sake of forcing people to move isn't a
good thing. It should bring something to the project.

Post by Andreas Mueller
What would we actually gain? There are two fixes in
sklearn/utils/fixes.py that we could remove, I think.

I wrote this mail because of:
https://github.com/scikit-learn/scikit-learn/pull/5889/files#r48728184

Post by Andreas Mueller
Also: what does dropping 2.6 mean? Writing in the docs that we don't
support it any more?
Shutting down the continuous integration? Removing the fixes?

All 3, IMHO.

Post by Andreas Mueller
If we remove the fixes, we force users to upgrade, with little benefit
to us, right?

Well, those fixes are a long-term maintenance burden. That said, it seems
that we have only 2 so far. I suspect also that in many places people are
avoiding more idiomatic Python patterns that are not supported in
Python2.6, but would lead to better code (as in the discussion I link to
above). Finally, it is a burden for contributors, that have to keep in
mind Python 2.6 compat (and often fail too).

The benefit to us should be better maintenance and easier development. If
it's not the case, we shouldn't do it :).

Gaël


------------------------------------------------------------------------------

[Joel Nothman]

I have many times committed coded and had to fix for python 2.6.

FWIW: features that I have had to remove include format strings with
implicit arg numbers, set literals, dict comprehensions, perhaps ordered
dicts / counters. We are already clandestinely using argparse in benchmark
code.

Most of these are fairly infrequently needed in our codebase, but some are
particularly useful for succinct doctests. If we made a concerted effort to
rewrite code more Py2.7+-idiomatically we might touch a substantial
quantity, but we won't do that anyway.

If we take a more conservative approach and do not upgrade the requirements
immediately, what is the latest date we would upgrade to ensure officially
supported RHEL is not left behind?

Post by Gael Varoquaux

Post by Andreas Mueller
I'm not sure I'm for dropping 2.6 for the sake of dropping 2.6.

I agree. I find the attitude of the post that I mentionned a bit
annoying: dropping support for the sake of forcing people to move isn't a
good thing. It should bring something to the project.

Post by Andreas Mueller
What would we actually gain? There are two fixes in
sklearn/utils/fixes.py that we could remove, I think.

https://github.com/scikit-learn/scikit-learn/pull/5889/files#r48728184

Post by Andreas Mueller
Also: what does dropping 2.6 mean? Writing in the docs that we don't
support it any more?
Shutting down the continuous integration? Removing the fixes?

All 3, IMHO.

Post by Andreas Mueller
If we remove the fixes, we force users to upgrade, with little benefit
to us, right?

Well, those fixes are a long-term maintenance burden. That said, it seems
that we have only 2 so far. I suspect also that in many places people are
avoiding more idiomatic Python patterns that are not supported in
Python2.6, but would lead to better code (as in the discussion I link to
above). Finally, it is a burden for contributors, that have to keep in
mind Python 2.6 compat (and often fail too).
The benefit to us should be better maintenance and easier development. If
it's not the case, we shouldn't do it :).
Gaël
------------------------------------------------------------------------------
_______________________________________________
Scikit-learn-general mailing list
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general

[Andreas Mueller]

Post by Joel Nothman
FWIW: features that I have had to remove include format strings with
implicit arg numbers, set literals, dict comprehensions, perhaps
ordered dicts / counters. We are already clandestinely using argparse
in benchmark code.

You probably just write much nicer code than I do, so I didn't notice it
so much ;)

I'm not super convinced by #5889, as it is a helper script for a
tutorial that is not part of the test suite.

My gut feeling would be to drop the requirement as soon as we would have
to write another helper, or feel that
a particular PR (to the core package) could benefit substantially.

Post by Joel Nothman
We have yet to have any complaints other than concern trolls and one

individual who put in PRs fixing all sorts of things where we were
_already_ broken on 2.6 but just did not cover in the tests.

So... seems to be going pretty great for them.

------------------------------------------------------------------------------

[Matthew Brett]

Post by Andreas Mueller

Post by Joel Nothman
FWIW: features that I have had to remove include format strings with
implicit arg numbers, set literals, dict comprehensions, perhaps
ordered dicts / counters. We are already clandestinely using argparse
in benchmark code.

You probably just write much nicer code than I do, so I didn't notice it
so much ;)
I'm not super convinced by #5889, as it is a helper script for a
tutorial that is not part of the test suite.
My gut feeling would be to drop the requirement as soon as we would have
to write another helper, or feel that
a particular PR (to the core package) could benefit substantially.

Post by Joel Nothman
We have yet to have any complaints other than concern trolls and one

individual who put in PRs fixing all sorts of things where we were
_already_ broken on 2.6 but just did not cover in the tests.

Oh dear - what is a "concern troll"?

Matthew

------------------------------------------------------------------------------

[Olivier Grisel]

Yet another perspective:

I am currently working with Thomas Moreau @tomMoral on more robust
process management for joblib / multiprocessing and supporting Python
2.6 seems to be tedious to do correctly (we need to backport a lot of
code from more recent versions of multiprocessing) and will render our
code base much harder to understand and maintain over time.

+1 for dropping 2.6 support in scikit-learn because of that.

Also as a side note: PySpark developers plan to drop Python 2.6
support in the future as well:
https://issues.apache.org/jira/browse/SPARK-12661

[Fernando Perez]

And yet another, in case it helps you make this decision.

IPython's official statement on our website reads:

IPython supports Python 2.7 and 3.3 or newer. Our older 1.x series supports
Python 2.6 and 3.2.

This has been true for quite a while, and I can't really recall any
significant complaints about it.

Even people on RHEL have mechanisms for running 2.7-based stacks if they so
desire, so that's not a show-stopper. And if they are absolutely stuck
running on an old stack, chances are, they are running old versions of lots
of other stuff anyway, so telling them to run old versions of our tools
doesn't seem to add any particular pain.

Cheers,

f

[Andy]

This seems like a good motivation.
I think we heard a lot of people not having any issues, and more people
going this way.
So let's go for it?

[that is change the readme, change the build matrix, grep the source for
backports]

Post by Olivier Grisel
process management for joblib / multiprocessing and supporting Python
2.6 seems to be tedious to do correctly (we need to backport a lot of
code from more recent versions of multiprocessing) and will render our
code base much harder to understand and maintain over time.
+1 for dropping 2.6 support in scikit-learn because of that.
Also as a side note: PySpark developers plan to drop Python 2.6
https://issues.apache.org/jira/browse/SPARK-12661

[Nelson Liu]

Hi everyone,
Just my two cents: I echo the sentiments mentioned earlier in this thread,
and think that there is strong motivation to move away from 2.6 +1!

Nelson Liu

Post by Andy
This seems like a good motivation.
I think we heard a lot of people not having any issues, and more people
going this way.
So let's go for it?
[that is change the readme, change the build matrix, grep the source for
backports]

Post by Olivier Grisel
process management for joblib / multiprocessing and supporting Python
2.6 seems to be tedious to do correctly (we need to backport a lot of
code from more recent versions of multiprocessing) and will render our
code base much harder to understand and maintain over time.
+1 for dropping 2.6 support in scikit-learn because of that.
Also as a side note: PySpark developers plan to drop Python 2.6
https://issues.apache.org/jira/browse/SPARK-12661

------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Scikit-learn-general mailing list
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general