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? On 5 January 2016 at 06:31, Gael Varoquaux <gael.varoqu...@normalesup.org> wrote: > On Mon, Jan 04, 2016 at 01:22:12PM -0500, Andreas Mueller wrote: > > 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. > > > 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 > > > 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. > > > 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 > Scikit-learn-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/scikit-learn-general >
------------------------------------------------------------------------------
_______________________________________________ Scikit-learn-general mailing list Scikit-learn-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
