3 ms·

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 pyt

by aprdm 6y ago

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.

Flockster 6y ago
Backwards compatibility I understand, but which languages give forward compatibility? I mean how would that with new features even work?
- aprdm 6y ago
  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<.
  - Caligatio 6y ago
    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-using-setuptools/#python-requires https://packaging.python.org/guides/distributing-packages-us...
- coldtea 6y ago
  >Backwards compatibility I understand, but which languages give forward compatibility? Python used to offer it frequently. from __future__ import ...
- cozzyd 6y ago
  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.

by aprdm 6y ago

Flockster 6y ago

Backwards compatibility I understand, but which languages give forward compatibility? I mean how would that with new features even work?

aprdm 6y ago
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<.
- Caligatio 6y ago
  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-using-setuptools/#python-requires https://packaging.python.org/guides/distributing-packages-us...
coldtea 6y ago
>Backwards compatibility I understand, but which languages give forward compatibility? Python used to offer it frequently. from __future__ import ...
cozzyd 6y ago
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.