Hacker News Reader

Comment by techdragon | Hacker News Reader

Genuinely asking because you’ve described the sort of CI/CD problem that there are existing solutions to, things like the Open SUSE build service, red hat have their own tools, commercial services exist from several vendors designed to tackle these “operating system permutations” build problems... is one release a year with security fixes going back four versions... really too fast?

All the gory details about the release timeline are in PEP 602 - https://www.python.org/dev/peps/pep-0602/

View on HN

I believe the biggest issue is having non compatible additions to the language... for example, any code written in 3.8 with walrus operator will not work in python3.7.

That is IMO not ideal. If it was security fixes / new features / improvements with no new syntax then I would be OK.

I would say a lot of companies still have a very big legacy code base in 2.7... new services are created in docker using the latest python3 but desktop applications aren't as easy to upgrade constantly.

Some companies also use NFS to store python libraries (we release 100s of times per day) and make some wrangling of PYTHONPATH to allow applications to find dependencies. Having to support multiple (incompatible) versions of python at a workstation isn't a good problem to have.

Backwards compatibility I understand, but which languages give forward compatibility?

I mean how would that with new features even work?

Hm not exactly what I tried to convey. I guess I would love if python stopped trying to add new syntax so often.

Walrus operator, fstring, etc. should happen maybe once every two years ideally? Did we really need the walrus operator? The cost of adding it is making any library using it in python 3.8+ incompatible with runtimes of python3.8<.

In the ideal world, library developers would properly use the python_requires[1] option and dependency resolvers would correctly identify the latest version of a library that works with the installed version of Python. Unfortunately I have found that is not always the case.

When I make public modules, I personally weigh whether using a new feature is worth losing users stuck on an older version. That sweet spot for me right now is targeting Python 3.6 and using backported modules where necessary (e.g. mypy-extensions). I'm a big type hint fan and type hinting became much more usable in >= 3.6.

[1] https://packaging.python.org/guides/distributing-packages-us...

>Backwards compatibility I understand, but which languages give forward compatibility?

Python used to offer it frequently. from __future__ import ...

Code written in C89 can trivially link against code written in C18. This also mostly works in C++ as long as new features are not used at the interface level and you don't have an ABI migmatch (e.g. with stdlibc++ std::string, although that's possible to work around with proper configuration). Any language exporting a C FFI should work just fine.

Reply on news.ycombinator.com