How long does python upgrading take you? I think Python 3.7 to 3.8 was change my docker version and push to CI... 5 minutes later it told me all tests passed and I deployed to production??
I do strongly feel that removing functions from the core library is a huge no-no for point releases.
Adding new features will seldom break old stuff. It is the removing part that is hard.
(With the exception being when like a variable broke because it became a keyword, but if you made a variable something like async I am not sure you are entirely innocent).
The old version you implicitly claim is better isn't, it just doesn't have the warnings from their dependencies in place yet.
The warnings are useless if they're not from my code, so they get turned off once globally.
Yes, it is not your package that is responsible, but it still affects your application, you could open a ticket, or submit a PR. If you had that message you should also hold of with upgrading to newer python until this is resolved.
No, you idiot. It's a deprecated usage in a dependency.
What happens in the future is I update pandas, it stops using the deprecated numpy method, and the warning just disappears with very little action on my part.
It's a useless warning.
And submit a PR every time this happens? How about I request you pull me?
> If you had that message you should also hold of with upgrading to newer python until this is resolved.
1. Upgrading to newer python? Who fucking cares
2. Upgrading resolves the warning entirely.
Python 3.3 was release in 2012. You've had 8 years.
The OP should have dropped it because it's unmaintained, and a maintained replacement has existed for a long time: https://cryptography.io/
This is an especially important consideration for security-critical libraries like cryptographic libraries.
Pypi has an api (https://pypi.org/pypi/<pkg-name>/json) that can be leveraged to implement alerts like "this pkg last released 5 years ago, it might be dead!". I guess that's what the "security" package uses already. It would be cool if they added an option to report on this sort of thing.
> Deprecated since version 3.3, will be removed in version 3.8: The behaviour of this function depends on the platform: use perf_counter() or process_time() instead, depending on your requirements, to have a well defined behaviour.
I would be wary of any crypto library that continued to work with a warning for 8 years and no one bothered to fix it. Most likely no one was maintaining it.
It would be nice if library developers kept their code up to date, but that doesn't always happen. Python core devs know this; well all know this, yet they consciously screw with the core libraries with the principle, caveat emptor.
I don't understand why they don't ear-mark these changes for 4.0. These kind of things are a universal frustration with the community and they are so easily avoidable.
python3 -c "import ast; print(ast.arguments([]).args)"
The python despite having 3 digit versions apparently is not following semantic versioning. The major version number generally had not much significance (the python 3 was exception, 1->2 and what they are assuring us 3->4 won't be a big change)
"The ast module helps Python applications to process trees of the Python abstract syntax grammar. The abstract syntax itself might change with each Python release; this module helps to find out programmatically what the current grammar looks like."
This module is a bit special, because as they say, it supposed to reflect current python grammar. If they change grammar and didn't make it reflect it it would lead to different kinds of issues.
Lest you think informing users more clearly is a foreign concept to them, look at the dis module [1] for comparison. They're extremely clear the whole thing is implementation detail of CPython. If anything, after reading that, one would think your conclusion would be "ah, I should program against the AST then, not the bytecode". So you do that and then you're greeted with this nonsense! Obviously it's your fault for assuming there's anything stable to program against across minor releases.
This module exposes internals of python, and providing such guarantees would cripple development, because it wouldn't even allow for refactoring the code.
Most languages don't run into this because they don't expose internals like that. You typically extract that yourself and you accept it can change every release.
As for dis, that's very different, the bytecode is just an optimization of the CPython, python code could work perfectly fine without it, the bytecode was introduced to make it faster and other implementation won't use I would imagine that Jython and IronPython most likely don't implement it since they have their own (JVM and .NET)
ast on the other hand is expected to be identical if a language claims to be compatible with a given version, and you would expect PyPy for example to also provide this package.
Well. The container doesn't magically update itself. But FROM python:3.6 -> FROM python:3.8 doesn't seem that hard. Then again a flexible package manager (with recent repos) can do this as well.
I control what is installed on it.
Thankfully it's no longer my problem.
Man in 2020 if you are SSHing between boxes and upgrading python by hand, you really should invest in some devops. Even 5 hours a week.....
Still a lot easier to manage as docker volumes in k8s.
Our applications are mostly monoliths and the number of servers they use is quite constant.
But it does mean our Python version really only changes when we switch to the next Ubuntu LTR, and isn't always the same between different projects.
If I don't want to use OS packages, I have to decide to package, build, deploy, and maintain the Python packages, often in a way that separates it from the system Python package, while also managing any Python libraries we need (some of which may be C extensions and require compiling).
Whenever possible, I like to leverage upstream packaging so that I don't have to track security updates on my own.
I say this as someone who used to maintain the official Python.org RPM packages.
pygame supports python3 since 2016, python-opencv since 2018 at least
> I think Python 3.7 to 3.8 was change my docker version and push to CI