Drop support for Python 2.6 and 3.3 (to match pandas 0.18.0)

[jtkiley]

As a point for discussion, we should consider dropping support for Python 2.6 and 3.3 to match the recent changes in pandas for 0.18.0. Among other things, it looks like it may impact our pandas.compat imports. If we decide to follow, we may also want to look at the associated pandas versions that we test against on 2.6 and 3.3.

See:
pandas-dev/pandas#7718
pandas-dev/pandas#11988
pandas-dev/pandas#11273

[bashtage]

This only makes sense if pdr will only support pandas 0.18. If you want to have any backward compat, then I think it is necessary to continue to support 2.6/3.3.

[jtkiley]

I think backward compatibility would be fine, unless you tried to use the then-current pdr on 2.6 or 3.3. Otherwise, the then-current pdr should be fine with the current or (reasonably) older pandas and on 2.7, 3.4, and 3.5.

There are practical benefits, both for code (e.g. eliminating workarounds for 2.6 missing features) and contributions (e.g. the python installers for 2.6 and 3.3 do not work on OS X 10.11, making compatibility issues take significantly more time and effort to fix). For all of the reasons stated in the pandas discussions, it's unlikely that actual users are still stuck with these versions.

[jreback]

from a practical perspective anyone still using 2.6/3.3 is not getting updated on many libraries going forward (e.g. matplotlib, numpy soon in a bit). pandas dropping will force the hand of downstream libraries, but to be honest if you are 'required' to use an older version that you are still using a fixed set of deps anyway.

Further it is quite easy nowadays to use either virtualenv or conda to operate in user space.

These are a legacy burden on the package maintainers. So would encourage dropping obsolete versions.

[aisthesis]

+1 for dropping support for obsolete versions. It's hard to imagine why anyone would be locked into 2.6/3.3 or earlier.

[femtotrader]

+1 on dropping Python 2.6 support.

[davidastephens]

+1 - I dropped it from pandas-finance.

[jtkiley]

So, in terms of process, how should we do it? It's not my expertise, but to be constructive:

• Determine which issues/PRs (if any) should get fixed/merged while still supporting 2.6 and 3.3.
• Determine any needed improvements for documentation.
• Once those are done, release a new version (0.2.x).
• Clean up old version workarounds and land any waiting PRs.
• 2.7, 3.4+ release (0.3.0?)
• Business as usual.

[davidastephens]

@jtkiley Not my area of expertise either, but why don't we just drop support as part of the next release (soonish) - could be 0.3.0?

[jtkiley]

@davidastephens As a practical matter, I think that's fine. My guess is that the number of people on 2.6 or 3.3 using pdr is near (or exactly) zero.

My thinking above was that it might be nice to release the current state of the repo with 2.6 and 3.3 support so that version would be installed for anyone with old Python versions, and then release a version dropping old versions (0.3.0). But, I think it's a fair argument that it would not help any actual people.

Based on the discussion above, I'm not sure whether we're talking about 2.6 and 3.3 or just 2.6, but count me in for getting rid of both. There are more cleanup opportunities and strange bug frustrations avoided if we get rid of both. Among other things, the Python 3.3 installer does not work on a recent OS X.

[davidastephens]

Plus there haven't been many significant changes since the last release anyways.

Lets target a 0.3.0 release in the next couple weeks. I will create a release issue and move the tests for 2.6 and 3.3 to allowed failure.

[jtkiley]

Cool. Should we test against 3.5/pandas 0.18.0rc1 as part of that?

[davidastephens]

Good point, yes we should.