New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEPS: drop python 3.4 #15251

Closed
jreback opened this Issue Jan 27, 2017 · 19 comments

Comments

Projects
None yet
5 participants
@jreback
Contributor

jreback commented Jan 27, 2017

No description provided.

@jreback jreback added the Compat label Jan 27, 2017

@jreback jreback added this to the 0.20.0 milestone Jan 27, 2017

@jreback jreback changed the title from COMPAT: drop python 3.4 to DEPS: drop python 3.4 Jan 28, 2017

@gfyoung

This comment has been minimized.

Show comment
Hide comment
@gfyoung

gfyoung Jan 30, 2017

Member

@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.

Member

gfyoung commented Jan 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@jreback

jreback Jan 30, 2017

Contributor

@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.

Contributor

jreback commented Jan 30, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@gfyoung

gfyoung Jan 30, 2017

Member

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.

Member

gfyoung commented Jan 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jorisvandenbossche

jorisvandenbossche Jan 30, 2017

Member

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)).

Member

jorisvandenbossche commented Jan 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jreback

jreback Jan 30, 2017

Contributor

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

Contributor

jreback commented Jan 30, 2017

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

@jorisvandenbossche

This comment has been minimized.

Show comment
Hide comment
@jorisvandenbossche

jorisvandenbossche Jan 31, 2017

Member

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.

Member

jorisvandenbossche commented Jan 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jreback

jreback Jan 31, 2017

Contributor

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.
Contributor

jreback commented Jan 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gfyoung

gfyoung Jan 31, 2017

Member

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.

Member

gfyoung commented Jan 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jreback

jreback Jan 31, 2017

Contributor

@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).

Contributor

jreback commented Jan 31, 2017

@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 jreback modified the milestones: 0.20.0, 0.21.0 Mar 23, 2017

@jreback

This comment has been minimized.

Show comment
Hide comment
@jreback

jreback May 9, 2017

Contributor

if anyone wants to do this :>

Contributor

jreback commented May 9, 2017

if anyone wants to do this :>

gfyoung added a commit to gfyoung/pandas that referenced this issue May 9, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 9, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 10, 2017

@jorisvandenbossche

This comment has been minimized.

Show comment
Hide comment
@jorisvandenbossche

jorisvandenbossche May 10, 2017

Member

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

Member

jorisvandenbossche commented May 10, 2017

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 added a commit to gfyoung/pandas that referenced this issue May 10, 2017

@gfyoung

This comment has been minimized.

Show comment
Hide comment
@gfyoung

gfyoung May 10, 2017

Member

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 😄

Member

gfyoung commented May 10, 2017

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 😄

gfyoung added a commit to gfyoung/pandas that referenced this issue May 10, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 11, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 11, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 12, 2017

@jorisvandenbossche

This comment has been minimized.

Show comment
Hide comment
@jorisvandenbossche

jorisvandenbossche May 12, 2017

Member

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.

Member

jorisvandenbossche commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gfyoung

gfyoung May 12, 2017

Member

@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)

Member

gfyoung commented May 12, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@TomAugspurger

TomAugspurger May 12, 2017

Contributor

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.

Contributor

TomAugspurger commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jorisvandenbossche

jorisvandenbossche May 12, 2017

Member

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):

pandas-daily-downloads

Member

jorisvandenbossche commented May 12, 2017

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):

pandas-daily-downloads

gfyoung added a commit to gfyoung/pandas that referenced this issue May 12, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 13, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 13, 2017

gfyoung added a commit to gfyoung/pandas that referenced this issue May 13, 2017

jreback added a commit that referenced this issue May 16, 2017

DEPS: Drop Python 3.4 support (#16303)
* DEPS: Drop Python 3.4 support

Closes gh-15251.

* TST: Patch locale failure on Circle

pcluo added a commit to pcluo/pandas that referenced this issue May 22, 2017

DEPS: Drop Python 3.4 support (pandas-dev#16303)
* DEPS: Drop Python 3.4 support

Closes pandas-devgh-15251.

* TST: Patch locale failure on Circle

stangirala added a commit to stangirala/pandas that referenced this issue Jun 11, 2017

DEPS: Drop Python 3.4 support (pandas-dev#16303)
* DEPS: Drop Python 3.4 support

Closes pandas-devgh-15251.

* TST: Patch locale failure on Circle
@chris-b1

This comment has been minimized.

Show comment
Hide comment
@chris-b1

chris-b1 Sep 5, 2017

Contributor

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.

Contributor

chris-b1 commented Sep 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@TomAugspurger

TomAugspurger Sep 6, 2017

Contributor
Contributor

TomAugspurger commented Sep 6, 2017

@chris-b1

This comment has been minimized.

Show comment
Hide comment
@chris-b1

chris-b1 Sep 8, 2017

Contributor

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.

Contributor

chris-b1 commented Sep 8, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment