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.
1 Like
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 sanic with 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 python3.5.
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 |
3 Likes
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.
In addition to deciding what to do about #1509, there is the issue relating to #1475 (ASGI support) and its associated PR #1562 (a new test_client using requests-async instead of aiohttp).
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 42101) using 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.
While using 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. - Switch
requests-asyncforaiohttp. - 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==18.12.0 or sanic==19.3.1 since 2019-01-01.
| python_version | download % |
|---|---|
| 3.7 | 40% |
| 3.6 | 38% |
| null | 12% |
| 3.5 | 9% |
| 2.7 | 1% |
| 3.4 | 0% |
| 3.8 | 0% |
| 2.6 | 0% |
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.
1 Like
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.
1 Like
@ahopkins @sjsadowski I like this idea. This way, we have enough time for people to take care of their migration effort and we also end up providing support until python 3.5 reaches EOL.
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.
1 Like
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.
Almost a year later, it seems that 3.7 is now widespread enough for 3.6 to be dropped too. Asyncio incompatibilities (like loop parameters mandated in 3.6 and depracated in 3.8) and typing are probably the biggest reasons to do so but these things are still quite minor nuisances. The walrus operator would be useful too, but it’ll take at least another year until 3.8 becomes common and frankly that’s something I can live without.
I’m guessing that maybe this is something we could target for 20.6 depending on how vociferous the objections are. As python3 seems to have stablized around the 3.7 tree for most major linux releases, it certainly doesn’t hurt my feelings too much.
At my workplace we’ve only recently started retiring Ubuntu 16.04 VMs (as its now nearly 4 years since they were provisioned), and moving to new VMs based on Ubuntu 18.04. That means we are literally just now moving from Python 3.5 to Python 3.6 on our servers. And just now moving from Python 3.5 to 3.6 as the target python version for our internal applications.
I know that’s not the problem of the sanic project, and nor should it be, but I am just putting it out there that Python 3.6 is still considered a shiny new python version to some.
Its not too big of an issue these days anyway because we try to run our applications in docker containers as much as possible now, and we tend to use containers with Python 3.7 internally.
I am leaning more in agreement with @ashleysommer on this. Python 3.6 still has a year and a half of support left. I think that we should at least keep it supported through 20.12LTS and if supporting it becomes a hindrance (like 3.5 did), then we have an LTS with 3.6 though its EOL.
Does anyone foresee any problems hanging on to 3.6 through the end of the year?