Do python releases introduce backwards-incompatible changes (ignoring the 2.x/3.x divide)? Would it not be as simple has making sure you have the latest runtime?
In theory homebrew takes care of the whole thing for you but, in practice... as an only part-time OS X user I have run into a lot of problems with the path getting set in various ways that end up in various copies of the Python interpreter or library paths getting loaded, resulting in runtime errors due to library versions being inconsistent with the interpreter version or expected libraries not being loaded...
A further complication is that, the specific way that Apple vendored a set of python packages, it is possible but not particularly easy to add new packages to the OS-provided Python runtime, so most users, if they want some package that Apple didn't include, seem to end up installing a whole new environment just to get that package, even if the OS-provided environment were otherwise acceptable to them.
It's a very real problem and very frustrating, but I'm not quite willing to blame it on the Python ecosystem because it seems to be pretty much a result of Apple's decision to ship an interpreter and set of libraries that most users will end up being unhappy with. Anecdotally at least I run into these issues a lot less on Linux because even with fairly stable distributions (e.g. RHEL7.5/8) the included interpreter and library are more recent and the package repositories include most of the Python packages you would want, maintained to match the OS interpreter version. So while some people do end up using virtual environments it's less necessary than it is on OS X, where it frankly seems near impossible to do anything without installing a whole second Python environment and munging paths.
An extra complication is that, as a casual OS X user, it seems to me like OS X terminal emulators and tools are more likely to munge with the path than Linux terminal emulators and tools, so even if you get everything set up "just right" you end up having it not work properly in certain contexts like plugins because something has modified the path for some reason.
Edited to expand that, I guess what I mean to say but failed to articulate, is that the fundamental problem here (in my opinion) is that OS X ships with a Python distribution but not with a package manager. That's the fundamental difference from Linux where these problems are much less common. Third-party package managers like Homebrew and Macports are used, and in order to have full control of the Python environment they have to install a whole second copy because they are not allowed to tamper with the OS X Python environment. This pretty inevitably leads to frustration. The best solution would seem to be for Apple to provide some kind of "first-party-ish" package management functionality, perhaps something like Chocalatey which is not a Microsoft product but is built on Windows-provided primitives, so that the package managers that users are actually using can play nicely with the OS X Python environment.
This might be a function of the casualness rather than the tools. Here's a thing to check out on OS X:
man path_helper
Homebrew can help with distinction, letting the user install to `/usr/local/bin/python` while the OS continues to use `/usr/bin/python`. My personal solution is to install Python packages into my homedir (--user) or use virtualenvs. This also helps when six months from now you want a "clean" setup.
I've pushed any organization I've worked at who heavily relies on Python to decouple Python from the OS because of this and so OS updates can be independent of Python updates.
GUI apps not being able to access $PATH is a big one, I have found.
Setting aside all other axes of comparison, it sounds like Node really learned from Python with regards to this problem. Install Node itself, do an NPM install, and you're golden.
About the only thing that reliably works besides "install Docker" is getting a bash shell going and pasting in a curl link, assuming your operating system is supported by whatever it is. That said, a close runner-up, that doesn't require bash and curl to be installed, would be Node's npx. Just run it, and "it works" even if whatever it is isn't installed. (Unless whatever it is doesn't have a precompiled binary for your system published and you then need to install CMake and compile tool chains like Xcode or Tools for VS)
It is because Python 3.7 makes "async" a reserved word, which was a valid identifier name before.
Now, there are actual backwards-incompatible changes that aren't made after at least two versions of deprecation, but those tend to be low level and subtle.
[1] https://docs.python.org/3.4/library/asyncio.html
[2] https://docs.python.org/3.5/library/asyncio.html
More on provisional API:
https://docs.python.org/3.8/glossary.html#term-provisional-a...
> A provisional API is one which has been deliberately excluded from the standard library’s backwards compatibility guarantees. While major changes to such interfaces are not expected, as long as they are marked provisional, backwards incompatible changes (up to and including removal of the interface) may occur if deemed necessary by core developers. Such changes will not be made gratuitously – they will occur only if serious fundamental flaws are uncovered that were missed prior to the inclusion of the API.
So maybe you were using "async" as a variable name, or as a function name in your code, and suddenly that wouldn't work anymore. It definitely is a backwards-incompatible change, and that has nothing to do with provisional APIs.
Since I have never use "async" as an identifier in my own code, I have no idea if warnings were issued, though probably?
gp specifically links to a SO question discussing asyncio.async breakage, which would be considered API breaking except it was specifically provisional.