5 ms·
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
by 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 agoWhy 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 agoMajor 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 agoYou're describing something like semver, but Python doesn't do semver.
- dmurray 7y agoAnd this change would be fine even if Python did.
- gnulinux 7y agoWho 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 agoIf 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 agoIf you write code that doesn't work in 3.5, you should check the version at startup and exit
- jakear 7y agoYes, 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 agoMost projects use setuptools for package management, which ensures that the environment is as expected.
- orf 7y agoSetuptools 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 agoIf 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.
- orf 7y agoYes, a failure to understand how your tools work or how to use them effectively does indeed make things harder.
- recursive 7y agoECMAScript recently got stable array sorting. That can cause precisely the same kind of backwards-incompatible but difficult to diagnose bug.