-
Notifications
You must be signed in to change notification settings - Fork 623
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
Decide supported Python 3.x versions (current code is 3.4+) #25
Comments
It looks like we've got two options to support pre-3.7 python versions: rearrange the classes in the module or use string-valued annotations. From PEP 484:
|
From SIG call: we'll support 3.4 and have no specific plan to drop support in the future. |
According to https://www.python.org/dev/peps/pep-0429/ and https://devguide.python.org/devcycle/, Python 3.4 is already EOL since 2019-03-18. Also pip complains: |
Like the 2.7 deprecation, we're likely to have a lot of users that still rely on officially deprecated versions. So we have a tradeoff: do we support more users and eat the higher maintenance cost (restricted feature set, use of backports, required use of old versions of tools like FWIW the 2018 JetBrains python developer survey reports that ~80% of users were on a version later than 3.4 as of fall 2018. Anecdotally, we tend to see large customers on older versions of python. I'd expect these customers to represent a small percentage of developers in the survey but a large percentage of end users. Another argument for being liberal with our minimum required version is that we want to make it easy for other libraries to depend on OT. Setting a high minimum python version means that we may lose instrumentation for another library that sets a lower minimum version -- even if the project that imports the other library is actually using a compatible version. |
Python 3.4 and "other Python 3.x version" account for 5% in that survey. But what we could do is create a Python 3.4 build and see how much trouble it causes compared to a 3.5 build and decide then. I also reopened this because I felt like in the meeting we only agreed on supporting definitely nothing older than 3.4 but did not clearly decide on supporting 3.4. |
That's a good point, we can keep it open until we've got a decision on 3.4 support. |
#46 adds testenvs for 3.4, 3.5, and 3.6, but doesn't (yet) run them during CI. |
Hi there, Probably, it's time to drop support for Python 3.4. |
Any thoughts? |
We should discuss this in today's SIG meeting (8:00 PST, see https://www.google.com/calendar/event?eid=NnNvbTJjYjZjZGdtNmJiMzc0cDNnYjlrNzFpbTJiOW9jOHIzNGI5aGM1Z2owYzlwYzhzbThkYjNjZ18yMDE5MDgyMlQxNTAwMDBaIGdvb2dsZS5jb21fYjc5ZTNlOTBqN2Jic2EybjJwNWFuNWxmNjBAZw) |
@Oberon00 Am I free to join the SIG meeting using Zoom? |
Of course! 😃 The SIG meetings are open to all interested parties (see https://github.com/open-telemetry/community#community-meetings). You are very welcome to join! |
Things that need or work better with 3.5:
|
Notes from SIG meeting 08/22:
|
Related to #62. |
Related #101 (if we use the contextvars backport, we might not need our thread local contextvars implementation). |
Python 3.5 has typing.ContextManager[T] (see #198 (comment)) |
Important to note that the contextvars backport currently doesn't support asyncio: MagicStack/contextvars#2 |
The aiocontextvars package was created as a workaround to this problem. Nevertheless, I have found it to produce wrong results too. This means that we currently don't have a way to use |
Agree with this. In OT we faced this problem too and one of the solution is patching contextvars with patched |
But, didn't you find any issues with aiocontextvars, @condorcet? I tried it yesterday and got this error. 🤷♂️ |
Thanks to @condorcet, I have been able to close the previous issue I mentioned (thank you, @condorcet!). Now, we are only facing this other issue for the oldest versions of Python 3.5. |
@toumorokoshi points out that we need to document the quirks around 3.4 support to close this. We'll keep supporting 3.4 for now. |
FWIW, the number of packages that are dropping Python 3.4 support is growing. For example installing docker-compose in Python 3.4 now requires pinning the version of PyYAML to 5.2. It might be worth revisiting removing support for 3.4 sooner than later. |
Closing for now, will reopen in the future when it's time to drop 3.4 |
With EOL for Python 3.5 approaching this Sunday (2020-09-13), is it now time to revisit this issue? |
* Add package: opentelemetry-types * Fix review comments * Fix README
In #14 we decided not to support Python 2. But with the current code base, we do not even support 3.6, even though
setup.py
claims we support 3.4. While it would be nice to be on 3.7 only, I think we should at the very least support 3.6. Demo:This is PEP 563 which requires 3.7.
Type hints in general seem to be supported since 3.5 / PEP 484. But note that instance/class variable type hints would only be available since 3.6 (PEP 526).
The text was updated successfully, but these errors were encountered: