DEPS: drop python 3.4

[jreback]

No description provided.

[gfyoung]

@jreback : Besides, removing it from the Travis YAML, is it possible to also drop support for library versions that were needed to be compatible with Python 3.4 (e.g. numpy)? I imagine that the code that is "Python 3.4" compatible is actually just code compatible with older library versions.

[jreback]

@gfyoung not sure what you mean. numpy 1.7 is compat with 3.4 (in theory), so nothing really to drop here (except the actual version support / travis). I think code changes are minimal as well.

[gfyoung]

I was referring to the fact that direct code "hacks" to be compatible with Python 3.4 are likely minimal as you said. Sounds good.

[jorisvandenbossche]

Is this already necessary? If it would not give much code clean-up, it is not much effort to keep compatibility a bit longer?
For 0.19.2, still 10% of all conda-forge downloads were for 3.4 packages (I know conda-forge stops with 3.4, but this percentage can be indicative for other downloads (main conda channel, pypi)).

[jreback]

well that's the point. As the rest of the community drops support, then we should as well.

[jorisvandenbossche]

conda-forge alone is not "the rest of the community" (and I suspect the main reason for dropping is that otherwise their build matrix becomes too large). I don't know of any other core packages already dropping support? Not that we can't be the first, but still wondering the necessity of this.

[jreback]

well the reason I put this on here is:

1. conda-forge dropping, so that means NO conda packages (not sure if defaults will have this for 3.4 or not, though I think it would have to be a request).
2. OUR build matrix is encumbered by this. So to be honest we could still support it w/o explicity testing it.

[gfyoung]

To be fair, breaking the 3.4 builds is not disastrous since they are allowed to fail. One other thing, have we given users any notice of dropping support for this version?

If we haven't, I would be inclined to agree with @jorisvandenbossche that we should wait. Perhaps we could warn in the next major release of the impending loss of support and then remove support for it in the next major version.

[jreback]

@gfyoung just want to clarify. just because something is allowed to fail, doesn't mean it actually is!

These builds are there because we want to exhaustively test things, but give quick feedback that for-the-most-part things work (hence the 5 main builds). And travis allows 5 concurrent builds so generally this fits well.

Yes, they can occasionally fail, but we do fix them!

If we eliminate the 3.4 builds then we won't know that they are failing. Though I will admit 3.4 is highly compat with 3.5 so I suspect that it would be unlikely for a 3.4 build to fail while a 3.5 one works (though possible).

[jreback]

if anyone wants to do this :>

[jorisvandenbossche]

Repeating my comment of above: is this necessary?
If there is actually almost no code clean-up that we can benefit from, but it is only about testing, I don't think it is that hard to keep one build on circle ci with the lowest supported versions

[gfyoung]

Perhaps...but mind you that we are pretty vigilant about making all builds pass, so not having to worry about making Python 3.4 builds work helps 😄

[jorisvandenbossche]

so not having to worry about making Python 3.4 builds work helps

Are there many example were this was actually a concern? (if you already have to ensure it passes on both python 2 and 3, I don't think there are many things you can do wrong for python 3.4)

[@jreback] 3.4 is not very well supported by conda anymore, no point in us holding out the torch.

python 3.4 is perfectly supported by conda, through anaconda (just not by conda-forge, but this is only part of conda users).

It would be nice to have some Anaconda download statistics on versions to have a better funded opinion about this.

[gfyoung]

@jorisvandenbossche: True, but I can turn that argument around and say then why not just test on the later versions of Python? (Works on those, should probably not break on Python 3.4)

[TomAugspurger]

From PyPI. I can't remember what timespan this covers.

Row	py	c	 
1	2.7	18114	 
2	3.5	3297	 
3	null	3037	 
4	3.4	2092	 
5	3.6	2025	 
6	2.6	1751	 
7	3.3	19	 
8	3.2	2	 
9	3.7	1	 

So 3.4 is a bit more popular thatn 3.6 AMT across all versions of pandas. I might be able to get the anaconda.org download numbers.

[jorisvandenbossche]

If we can rely on those pypi download stats (and probably a lot of CI included in there as well), there is actually a quite impressive increase over the last months (daily download counts):

[chris-b1]

Apologies for being several months late, but I think this was too aggressive and we should support python3.4 for 0.21. 3.4 is a perfectly functional version and still the only python 3 in some environments (e.g. some AWS platforms)

It would be one thing if there was actual clean-up / maintenance benefit by dropping it, but doesn't seem to be much? We can certainly keep the CI light on 3.4.

[TomAugspurger]

I believe Joris was also concerned about this (or at least not convinced that the payoff in code cleanup wasn't worth it). I haven't closely tracked code changes that we've implemented. Perhaps submit a PR that re-enables a worker with python 3.4 and see what breaks?

…

On Tue, Sep 5, 2017 at 3:21 PM, chris-b1 ***@***.***> wrote: Apologies for being several months late, but I think this was too aggressive and we should support python3.4 for 0.21. 3.4 is a perfectly functional version and still the only python 3 in some environments (e.g. some AWS platforms) It would be one thing if there was actual clean-up / maintenance benefit by dropping it, but doesn't seem to be much? We can certainly keep the CI light on 3.4. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#15251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABQHIu6t0kNrNRaJ63QrGA2q4LvIGkEBks5sfa0sgaJpZM4LwU5t> .

[chris-b1]

Thanks, yes, I'll put something up. @jreback is right that it is a bit of a pain due limited availability of 3.4 packages in the conda channels, but I do think it's right thing to do for this release, then would be fine immediately dropping 3.4 in master.