Skip to content
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

Python 2.7 support #14

Closed
carlosalberto opened this issue Jun 7, 2019 · 11 comments
Closed

Python 2.7 support #14

carlosalberto opened this issue Jun 7, 2019 · 11 comments

Comments

@carlosalberto
Copy link
Contributor

The current effort discards Python 2.7 support, and stick to the 3.x series. However, I know a few other vendors might need to stay compatible with 2.7, so I'm creating this ticket in order to track this.

@carlosalberto
Copy link
Contributor Author

cc @yurishkuro

@yurishkuro
Copy link
Member

No objections. Python 2.7 is EOL by the end of 2019.

@carlosalberto
Copy link
Contributor Author

Any input on this @palazzem?

@palazzem
Copy link

Thanks for the ping @carlosalberto! Yes I don't have any objection. As a vendor we're continuing to support Python 2.7 even a bit after EOL. But that will be a dedicated version with that support, so we don't have any concern and is aligned with our upstream.

@carlosalberto
Copy link
Contributor Author

Closing this issue based on the feedback from OpenTracing developers.

@c24t
Copy link
Member

c24t commented Jun 19, 2019

As I understand it, we're planning for the "last" releases of opencensus-python and opentracing-python to depend on this project, and effectively forward all calls to the new client. Dropping support for python 2 here means these last releases won't support it either.

This seems like an acceptable tradeoff to me since users can still use older versions of each client, just not the one that adds the dependency on opentelemetry.

@untitaker
Copy link

untitaker commented Sep 24, 2019

I believe that the argument "users on 2.7 can still use the older clients of each apm provider" only successfully shows why existing, longer-standing APM providers (datadog, newrelic) do not have much of an incentive to push otel into a direction to support 2.7. That argument cannot be used to prove why the move to drop 2.7 is in the common interest of making otel a standard.

@Oberon00
Copy link
Member

Oberon00 commented Sep 25, 2019

It is a move in the common interest of making Python 3 a standard 😅

EDIT: More seriously: There is no doubt that supporting 2.7 would increase adoption of OpenTelemetry. However, I don't know by how much. There is also no doubt that it will increase complexity of development for OpenTelemetry Python and slow it down. Not only initially when changing everything to support Python 3, but continuously, as (1) supporting Py3-only features while still maintaining 2.7 compatibility will continue to require extra code for new features and (2) tools and libraries we depend on will probably continue to drop 2.7 support (e.g. you need to install python2 yourself in the latest Ubuntu versions).

@untitaker
Copy link

untitaker commented Sep 25, 2019

It is a move in the common interest of making Python 3 a standard 😅

The goal of any standardization process is to increase adoption of the standard. Beyond that I believe things like "increase adoption of Python 3" can be a goal, but I don't see that stated anywhere. I do agree that Python 2 is maintenance burden, but to me that tradeoff is still worth it.

However, I don't know by how much.

50% of our users (sentry.io) are on Python 2. 50% of PyPI downloads are Python 2.

Here's how I found out the latter:

  1. dataset: https://packaging.python.org/guides/analyzing-pypi-package-downloads/
  2. query: SELECT substring(details.python, 0, 1) as v, count(1) FROM [the-psf:pypi.downloads20190925] GROUP BY v

Results:

Row v f0_  
1 2 22176965  
2 null 1851633  
3 3 26276828  

@untitaker
Copy link

Obviously sentry.io would like to see an opentelemetry that aims for 2.7 compatibility. But despite what I wrote above, I still don't have a strong opinion on what outcome is best for otel as a standard. The concerns about maintainability are valid, and you could argue that by the time otel is ready Python 2 usage will have decreased significantly. So that's a bet on the future of Python 2 I would understand. But I don't think the decision can be justified with the usage stats we have today. So it would be a long-term bet in my eyes.

@Oberon00
Copy link
Member

What the usage stats don't show is how many of these projects are in maintenance-only mode and won't incorporate a new technology like OpenTelemetry anyway. I suspect the proportion is higher for 2 than 3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants