5 ms·

What you describe is forward compatibility, and Python (and most other programming language) doesn't have it.

• jakear 7y ago
  Usually languages don’t have it in a very explicit way though. If I try to use f-strings in python 3.5 I get a very explicit syntax error. If I rely on ordered insertions in Python3.5 I get a potentially difficult to diagnose bug.
  • gnulinux 7y ago
    Why does it matter if it's explicit or not. If python doesn't support forward compatibility, you should know that if you write code for 3.7, it's not gonna work in 3.5. Doesn't seem like a big deal to me.
    • rmdashrfstar 7y ago
      Major version changes are for API compatibility. If there is a change which makes all other 3.* incompatible, then it should be a major version increase.
      • eatonphil 7y ago
        You're describing something like semver, but Python doesn't do semver.
        • dmurray 7y ago
          And this change would be fine even if Python did.
      • gnulinux 7y ago
        Who told you that? I'm looking at PEP 606, it says nothing like what you claim. https://www.python.org/dev/peps/pep-0606/ https://www.python.org/dev/peps/pep-0606/
    • jakear 7y ago
      If you’re the only one writing it and you’re the only one running it, it’s probably fine. But if I’m putting a file out there that will only work in 3.7, it’d be nice if any potential users of that file would get a good error message if they try to run it on 3.5, rather than wrong results. I could potentially assert a version, but do I really want to do that each time I wrote something that might be used somewhere else? And yes of course I could add a line of documentation, but there is a 100% chance I’d still get bug reports from people on 3.5.
      • lonelappde 7y ago
        If you write code that doesn't work in 3.5, you should check the version at startup and exit
        • jakear 7y ago
          Yes, that would be a good idea. But if you ever run scripts you didn’t write, there’s the potential people didn’t do this, and you have the potential for hard to discover bugs. The language should be designed such that bugs are difficult to encounter, this is an instance where it wasn’t.
      • zeulhex 7y ago
        Most projects use setuptools for package management, which ensures that the environment is as expected.
      • orf 7y ago
        Setuptools solves this, add a python version specifier to your setup.py or pyproject.toml file. If you are just distributing raw python files then congratulations you’ve just realised why packaging is valuable.
        • Aachen 7y ago
          If I rely on a python version and I expect other people to use it, I add a version if statement on top. I hate those packaging tools that insist on installing stuff in your system and create a frankendebian when really all I want to do is run a single py file standalone once. Often have to do chenanigans like "python3 -c 'from sometool import __app__'". If you want to install it, go ahead and copy or symlink it in your ~/bin or whatever you fancy (that's your personal preference anyway unless I'd specifically package it for some OS like Debian). I don't want to have to use some setup.py that I have no clue where in my OS it installs things.
  • recursive 7y ago
    ECMAScript recently got stable array sorting. That can cause precisely the same kind of backwards-incompatible but difficult to diagnose bug.
• abetlen 7y ago
  TIL I suppose Python doesn't even have backwards compatibility within the same major release as we saw with the addition of the async keyword in Python3.5. Many older Python 3 packages broke because they expected that to be a legal identifier for a variable name.
  • hprotagonist 7y ago
    tensorflow didn't work on 3.7 for a solid 8 months because some people at google very unwisely decided that `async` and `await` were great choices for variable names, despite PEP492 landing in 2015.
    • fock 7y ago
      that's because tensorflow is advertisement for Google and while it's technically open-source, it doesn't stand for any kind of community-project, it's all there to show off (and ingrain in its users) the way Google wants things to Go (just look at the byzantine Bazel-build-processes - tensorflow taking hours to build and pytorch about 10minutes...).
      • hprotagonist 7y ago
        my torch builds also take hours. facebook is just as capable of writing hot garbage, sadly.
        • fock 7y ago
          Yeah, still it's an order of magnitudes faster...
  • VWWHFSfQ 7y ago
    Python has never tried to maintain backwards compatibility within a major release
• deleted 7y ago
  [deleted]