Hacker News Reader

Comment by haihaibye | Hacker News Reader

These are cute, but I disagree with the suggested use case of putting them at the start of files to throw syntax errors to check Python versions.

Just check values in sys.version_info then throw an exception, it's so much more obvious what you're doing.

View on HN

If the source file contains syntax that is invalid on the user's Python version, then your code that's supposed to check the version and throw a helpful exception will never run. Instead the Python interpreter will throw a syntax error the first time it tries to parse something it doesn't recognize, and that syntax error may not make it obvious what the problem is.

This is a good point, but can’t you do it in __init__.py? I thought that ran first

An entire file is parsed first, before any code in it is run.

If your __init__.py didn’t have any version-specific syntax, then yes you could check the interpreter version before importing the rest of the files.

One minor benefit of a compile-time version check, is that when the check fails, you're not left with useless .pyc files.

Besides, __init__.py doesn't always exist.

If you're trying to make a version-robust module that won't attempt to compile a syntax error, top-level dispatch through __init__.py is an excellent approach.

Ok, that's a real problem, maybe we need a PEP for a minimum version in the header eg:

    # -*- python >= 3.1 -*-

The trouble is, that wouldn't work on the old versions!

>The trouble is, that wouldn't work on the old versions!

Yeah, a bit late to address the issue. Would have been helpful in the 2->3 transition.

The best time to adopt it was in 2.X, the second best time is now....

PyPA has basically done that with pyproject.toml/Pipfile and pyenv.

If somebody else is running the code, it likely is packaged. Every python packaging I know allows to specify version of python to use so IMHO that's what should be used.

>If somebody else is running the code, it likely is packaged.

Partially because people avoid Python for things like installers and simple sharable single file scripts...because of this. There are ways around it in many other scripting languages. And a fairly good number of popular "single file scripts" that get shared, like mysqltuner (perl), adminer (php), etc.

Hmm in those instances I think this would be much better solution: https://nixos.wiki/wiki/Nix-shell_shebang#Python

Instead of checking whether proper version is used, why not just ensure it runs on right now (and perhaps includes needed dependencies)

Of course, there's the catch-22 that they probably don't have nix-shell.

I was about to ask, what is the goal of this? Is this to prevent users from removing version guard and force-running the code with older version anyway?

If it's a single file script, checking sys.version only works if all your code is syntactically correct for that version. It's a shortcoming of python's approach of parsing the whole file before handing control over to your code. Basically, the interpreter bombs before it ever runs your "sys.version" code.

It's actually a fairly practical approach, where you are controlling where the code is going to bomb out, and including a helpful comment that will show in the stack trace / exception.

With Perl, for example, you can have a BEGIN block to check for versions, and it works as expected, even if there's code in the main body that's too new for whatever version of Perl is running. Python doesn't have that ability unless your code is split across more than one file and using conditional imports. Some BEGIN block type functionality for python seems like it would have been useful to me.

Reply on news.ycombinator.com