[jakear]

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]

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.

[jakear]

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.

[orf]

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]

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.

[orf]

Yes, a failure to understand how your tools work or how to use them effectively does indeed make things harder.

[Aachen]

Well I know how my tools work, I don't know how this custom file works that is duplicated and delivered with each project.

[zeulhex]

Most projects use setuptools for package management, which ensures that the environment is as expected.

[lonelappde]

If you write code that doesn't work in 3.5, you should check the version at startup and exit

[jakear]

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.

[fctorial]

#!/usr/bin/env python3.7

[gruez]

so now you have to install a specific python version for your script to work?

[fctorial]

Only if you're using version specific features.

[jakear]

What happens when python 3.8 comes out? Everybody needs to go into your script to change the hashbang every time a new release comes?

[rmdashrfstar]

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]

You're describing something like semver, but Python doesn't do semver.

[dmurray]

And this change would be fine even if Python did.

[gnulinux]

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/

[recursive]

ECMAScript recently got stable array sorting. That can cause precisely the same kind of backwards-incompatible but difficult to diagnose bug.