Just what the topic says. Stemming out of the PR here: https://github.com/huge-success/sanic/pull/1509
Python releases are now set to be supported for 5 years from their release date. So, Python 3.5 will be supported until September 2020.
I think as long as 3.5 is supported we should continue. Unless we have a compelling reason. Changing libraries does not seem like an overwhelming reason to drop support for a Python version.
I don’t disagree, but I wanted to start thinking about it - and get people prepared.
If 3.5 is supported until September 2020, should we be planning to bump the required version of python to 3.6 at that time? Or should we make the leap to bump it to 3.7? We have time to make the decision, so it doesn’t need to be a rash one, but it could shape how we prune code and implement features.
I did a bit of digging to find out the usage of
python3.5 and here is what I found. Stats URL
And a total of 43k downloads have been reported in the last 100 days. That seem to be a pretty large number of downloads. So, at this point, adding a deprecated warning might cause an annoyance for a lot of users who are still on
However, I suppose we can start thinking about a possible strategy to deprecate support for this in the future and see what might be the best way to achieve this.
# Stats of Download for last 100 days | Python 3.5 | Python 3.6 | Python 3.7 | Python 3.8 | |---------------|-----------------|---------------|------------------| | 43801 | 152611 | 70459 | 38 |
Probably by the next LTS release, stating that any Sanic release after September 2020 may not support Python 3.5, although a lot of things may work after (IMHO) …
I think it is time to renew the conversation here. @core-devs and everyone in the community, input requested.
Also, see this conversation.
While I stand by my earlier statements, I am starting to feel that compelling reason for dropping Python 3.5.
To recap the position and state of ASGI adoption…
@tomchristie has been awesome enough to take a stab at a PR to give Sanic an interface for usage with ASGI servers. The problem is that our current
test_client stands up a service to hit (usually on port
aiohttp. The new
requests compatible async framework has an adapter built in that would allow us to use it to query an ASGI compliant version of Sanic without having to standup a service.
The problem is that it is 3.6+ only.
requests-async is not the only way to getting to ASGI, it certainly is one of the easier methods for an incremental adoption.
I am proposing that
version 19.6 takes the following steps:
- Officially cut 3.5 support, only in so much as we will not require 3.5 passage on
tox. But, not taking any steps to alter the code base right now.
- If possible to squeeze it in, also add preliminary support for ASGI.
I think we probably should go at least one more LTS version with the existing Sanic server, but perhaps we drop it somewhere in 2020. I am hopeful to still get ASGI into
19.6. If not,
19.9 should be the next option so that we have it at least one implementation before an LTS.
I have locally also started a new
sanic-test-client repo that I want to push once we have a resolution here. In addition to having
SanicTestClient, it will also include
SanicASGITestClient. Once we figure this issue out, I will push to either my private GitHub, or if we agree that we want to remove
testing.py from core, then to the community organization.
Here are stats of the Python version used for downloading
sanic==19.3.1 since 2019-01-01.
Just looking at this and seeing that we cover 78% of downloads with 3.6+ is good enough to warrant my vote to move the minimum python version - along with the improvements in async that happened post 3.5.
I would propose, however, that 18.12 LTS is extended through 2020 for 3.5 support, as if we make the move to 3.6 now, 19.12 (provided we designate it as LTS as is planned) will have a minimum 3.6 requirement.
So I understand your proposal…
18.12LTS is supported thru December 2020, with its 3.5 support.
19.12LTS is supported thru December 2021, having been bumped to 3.6.
This makes sense to me and will mean Sanic out lives the official 3.5 support thru September 2020.
Yes. Originally I think we talked about 1 year and the LTS being replaced with the next LTS, but this solves a number of issues with longevity and support.
If we are to do the 19.12LTS as 3.6+, then I suppose we can add deprecation warning starting the next cut of Sanic to inform a larger audience when they use latest sanic from PyPI.
I like this idea too.
The 18.12LTS can continue with security-only fixes and python 3.5 support for users who (like myself) are not yet able to move away from Python 3.5 in their environment.
And I’m happy to see future releases moving to Python 3.6+.
Being that @sjsadowski, @harshanarayana, @ashleysommer, and myself are all in agreement (and seeing no other dissenting opinions), I am going to go forward with PR #1562 under the assumption that it will be Python 3.6 only, and that we will extend LTS releases to two year support.
I will try to finish it up this week. If there is any more discussion, please feel free to continue.
Not sure where that leaves us with #1509 and
orjson. Perhaps some more benchmarking is in order.
I would say to go for 3.6, with the idea of having the previous LTS to provide support to Python 3.5 still (since we already took the commitment on supporting it, either by security fixes or providing the same Python compatibility when it was previously launched).
+1 on moving forward with 3.6
Updates to the standard lib may also enable us to look at a couple things
https://github.com/python/asyncio/pull/452 I think the community is gradually shifting away from passing the event loop around and instead invoking
get_event_loop()where necessary. I haven’t really looked at this in a while so I don’t have a strong vision on what this changes at the moment but is something I’ll look into
- I don’t know if we’ve ever had a conversation around type hints? 3.6 might be a better place to look into that
I started adding some type hints to the new stuff in #1475. Whether we keep them or not can be a conversation when I’m done. Personally, I think we can incrementally add them. Unfortunately there are some really helpful parts of them that are only 3.7+. But even at 3.6 support, I think there’s a place for them at the function definitions and returns.