We will update from python3.6 to python3.11 , but I don’t know whether my code is compatible with version python3.11.(there are a lot of code) ,Does python have some tools to check compatibility?
Not that I’m aware of.
When I have done this for work there has always been an extensive test suite with high coverage that I ran to confirm a python upgrade or python package upgrade was working.
It may be that your codemay break, not becuase of python itself, but becuase you will need to upgrade packages you depend on to versions that support python 3.11. Package upgrades have, in my experience, been the main focus of porting efforts.
2 Likes
I want high version python3.x can be compatible with lower version 3.x,like golang did.
Have you considered tox?
It’s designed for these kinds of situations - if you have an app or code you want to test in different Python environments, versions.
1 Like
It’s kind of odd since golang didn’t really do that all the time either: at least in their build tooling. Reminds me of getting confused about get and install being different depending on the go version.
Generally I’ve had good luck trying old py3 code on new py3 but have definitely hit gotchas.
The most recent one was code relying on fork being used on Mac for multiprocessing, but it swapped to use spawn by default recently.
I understand the concern, but the difference between Python 3.6 and Python 3.11 (why not Python 3.12?) is much smaller than the difference between Python 2.6/7 and any version of Python 3. I think a lot of worries people have stem from thinking that every Python upgrade is going to break some existing code, rather than being largely a superset of the previous version.
A lot of effort has been made to properly deprecate features that will be going away in future versions, to give people time to adjust, and very little syntax has changed. The only future statements that have become mandatory later than 3.0 are generator_stop (3.7, so you may need to check for that) and annotation (which still hasn’t become mandatory, but also wasn’t introduced until 3.7, so that’s not something your code will have dealt with anyway). Testing one step (3.7, then 3.8, etc) at a time should uncover any deprecation warnings you need to watch for.
2 Likes
We will update to new python version 3.11, because many cves on old version 3.6.x doesn’t fix.
It this why you will no be updating to 3.12?
If security is your concern you are better off upgrading to 3.12.
deprecation can receice,but many func will remove, golang will not remove even deprecation. The parameters of some functions may also change,golang will not.
undate python version have more risks than golang.
python may remove some funs
but golang will not delete even deprecation
So long as you have a good quality test suite for your code this is a low risk upgrade to make.
And as I said before upgrading packages is the bigger risk than python itself. But to fix CVEs you will have to upgrade packages.
If you lack a good quality test suite then, for a commercial project, you have bigger problems.
1 Like
It seems you are mainly concerned with fixing CVEs for dependencies running in older versions of Python, and your solution is to upgrade to a more recent version of Python, which then needs to be evaluated for compatibility issues.
What I would do first - if you have not already done so - is to set up a CI pipeline where one of the jobs is to run a fixed test suite against your code in all Python versions from 3.6 → 3.12. You could then inspect and compare the results - if anything breaks or there are inconsistencies you should see it there. Setting up the pipeline is pretty easy - I don’t know what CI provider you’re using, but provided you have a test suite you can do it fairly easily with GitHub Actions or Gitlab CI.
For CVEs, GitHub provides the Dependabot alerts service. I’ve used this, and it’s really quite easy to use. According to the Gitlab docs the Enterprise Edition (EE) seems to have a similar feature called Dependency Scanning, but this may also be available in the basic, free tier.
If your repository is on GitHub then you can easily enable Dependabot alerts, even for private repositories - this will result in automatic CVE alerts/notifications for your dependencies. There is also an option for Dependabot to automatically open PRs to fix these CVEs. But you could also create the fixes manually, if you prefer.
2 Likes
Then what’s the point of deprecating anything? Sounds like it’s just an opinion about not using something that developers can just ignore.
But nobody is saying that your code is guaranteed to work on upgrade, only that whatever breaks should be minimal and easy to fix.
I suppose if you wanted to examine the differences, assuming you have a 2.7 code base, you could use the conversion tools in both 3.6 & 3.11, then compare the results. As others have indicated though, you will find next to no syntactic differences. Any changes would likely be new converters or bug fixes in the conversion tools between 3.6 & 3.11.
I agree as well that you should update to 3.12. Any security fixes in 3.11 will also be in 3.12. In addition, 3.11 is one step closer to the grave (end-of-support) than 3.12.
I find redhat or anlios will fix cves even if python3.6 is end-of-support.
ref:Python support for Red Hat Enterprise Linux (RHEL) - Red Hat Customer Portal
https://gitee.com/src-anolis-os/python3/tree/a8/
You can try to put off the day when you upgrade but be warned the longer you wait the higher the costs.
1 Like
They get paid to do that 
And note that such fixes, even more than normal bug fixes, may break code, which people not exposed to the issue may not want.