4 ms·

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.

4 ms·

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

by Flockster 6y ago

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.