Python 2.7 support

[carlosalberto]

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]

cc @yurishkuro

[yurishkuro]

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

[carlosalberto]

Any input on this @palazzem?

[palazzem]

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]

Closing this issue based on the feedback from OpenTracing developers.

[c24t]

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]

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]

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]

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]

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]

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.