15

If I'm making a module that I would like to run the same in Python 2 as in Python 3, there are a ton of options including six, futures, and 2to3. If the number of changes is small though, each of those tools has enough quirks that I tend to prefer to just write a compatibility interface for the few incompatible functions my module actually uses.

A reasonably standard way to accomplish that is with a straightforward version check.

import module_bar

if sys.version_info >= (3,):
    uniformly_named_foo = module_bar.py3_thing
else:
    uniformly_named_foo = module_bar.py2_thing

Are there any oddball cases where sys.version_info wouldn't be reported correctly though? I've been bitten enough in the past by malformed paths, configs, installations, modifications, and whatnot that this doesn't feel like a thing I should trust.

When we get right down to it, what I actually care about is if a particular feature is implemented. In web development, it's generally recognized as a bad practice to sniff user-agents. Instead, one should do their best to identify if a particular feature is in use or not. Depending on the feature, there are many ways one could accomplish that.

if hasattr(module_bar, 'py3_thing'):
    uniformly_named_foo = module_bar.py3_thing
else:
    uniformly_named_foo = module_bar.py2_thing

On my machine, the second route is twice as slow (not that an extra few hundred nanoseconds really matter for a one-time operation), but it doesn't seem to have any other major disadvantages. Are there advantages though? Are there Python installations where the second approach will be successful and the first will fail?

Hans Musgrave
  • 6,613
  • 1
  • 18
  • 37
  • 1
    Yes it is. Why not? – iBug Sep 17 '18 at 01:42
  • Possible duplicate of [How do I detect the Python version at runtime?](https://stackoverflow.com/questions/9079036/how-do-i-detect-the-python-version-at-runtime) – Pedro Lobito Sep 17 '18 at 01:46
  • @iBug The "why not" stems from me not knowing what I don't know here. The question (here)[https://stackoverflow.com/questions/22236727/mismatch-between-sys-executable-and-sys-version-in-python] indicates that there could be problems. – Hans Musgrave Sep 17 '18 at 01:47
  • Possible dupe of https://stackoverflow.com/questions/1093322/how-do-i-check-what-version-of-python-is-running-my-script – DYZ Sep 17 '18 at 01:48
  • @Hans See the documentation: *Do not extract version information out of it* (`sys.version`), *rather, use version_info and the functions provided by the platform module.* See my edited answer. – iBug Sep 17 '18 at 01:49
  • @iBug, the question wasn't about the documented behavior so much as if there are any known instances of OS/distro/device manufacturers/maintainers botching up the installation so that `sys.version_info` isn't reliable. Sort of like how long integer modulo arithmetic is still broken for Python2 on codefights.com. – Hans Musgrave Sep 17 '18 at 02:11

3 Answers3

16

Yes. sys.version_info is a reliable way to determine Python version.

See Python 3 documentation and Python 2 documentation.

Note: sys.version_info is reliable, but not sys.version:

sys.version

A string containing the version number of the Python interpreter plus additional information on the build number and compiler used. This string is displayed when the interactive interpreter is started. Do not extract version information out of it, rather, use version_info and the functions provided by the platform module.

If you're worried about bad modules changing the values of sys.version_info or something else, you can force a reload of <module 'sys' (built-in)>:

import sys
sys.version_info = "boo"
print(sys.version_info)  # boo

sys.modules.pop("sys")
import sys  # reloaded
print(sys.version_info)
# Output: sys.version_info(major=3, minor=6, ...
iBug
  • 35,554
  • 7
  • 89
  • 134
  • The "Do not extract version information out of it" warning is mostly because 1) you're likely to get it wrong, and 2) the information is available through more convenient, safer options that don't require you to parse anything. – user2357112 Sep 17 '18 at 01:59
  • @user2357112 Well, that's what Python doc says. – iBug Sep 17 '18 at 02:05
  • @user2357112 I'd wager a bet that it's partially also because they're not promising formatting compatibility between minor versions. – Hans Musgrave Sep 17 '18 at 02:12
  • @iBug I like the fact that you fixed the `bad_dependency` problem, but `sys.modules.pop` isn't really safe if any other modules in that python instance depend on `sys`. Using `imp.reload` is fine for now, but deprecated for 3.4+. Arguably `imp.reload` will be around for as long as anyone really cares about 2/3 compatibility. Do you think that's a good enough cross-version solution? – Hans Musgrave Sep 17 '18 at 02:30
  • @Hans `importlib.reload(sys)` doesn't work. I just tested this on Python 3.6. – iBug Sep 17 '18 at 02:43
  • @iBug Not withstanding that `imp.reload` is the version that's also installed in Python 2.7, that's really interesting. It works correctly on all my Python 2.7 installations but not for any of my Python 3.6 installations. What alternatives avoid the negative effects of `sys.modules.pop()`? – Hans Musgrave Sep 17 '18 at 02:49
  • @Hans Not sure. I think it's safe if you import it again immediately after popping from `sys.modules`. – iBug Sep 17 '18 at 02:50
  • 1
    Screwing with `sys` like that is going to cause much bigger problems than the theoretical problem you're trying to solve. Now you have two versions of the `sys` module, and which one is actually used for anything is basically an initialization order-based crapshoot. Most of the interpreter internals will keep using the first version. – user2357112 Sep 17 '18 at 17:50
  • 1
    One of the most obvious, catastrophic ways that this breaks things is that the new version of `sys` **doesn't have a `sys.modules`**. Or a `sys.path`. Or a `sys.ps1`. Or a `sys.stdout`. Or a bunch of other really important things. – user2357112 Sep 17 '18 at 18:04
1

No, sys.version_info is not reliable, but only in the sense that almost everything in Python is overwriteable and because of how modules are singletons if no voodoo is being done. Consider the following example, which has one tiny typo.

# bad_dependency.py
import sys

# is_py3 = sys.version_info >= (3,)
is_py3 = sys.version_info = (3,)

What happens when we import this? Well...nothing good.

# our_module.py
import sys
import bad_dependency

print(sys.version_info)

When we run this, since sys is the same module everywhere and since we've overwritten the information we care about, we actually get the following behavior:

$ python our_module.py
(3,)

Of course by this metric almost none of our code is reliable if our imports have bad enough bugs. What's interesting is that it doesn't have to be our code that causes the problem, and the effects certainly don't need to be malicious.

As to the question of whether problems like this exist by default in some reasonably standard Python installations (e.g., micropython, OSX, etc...), I'm still not sure of the answer.

Hans Musgrave
  • 6,613
  • 1
  • 18
  • 37
  • See my edited answer for defending against `bad_dependency`. – iBug Sep 17 '18 at 02:16
  • @iBug I like that idea. I'm still holding out for anyone who knows of platforms with an incorrect `sys.version_info` (proving a negative is hard), but in a day or two I'll otherwise select yours as the best answer. – Hans Musgrave Sep 17 '18 at 02:32
0
import sys
sys.version_info.major

I think this is the best way to determine whether one is using Python 2.x or Python 3.x.

Boštjan Mejak
  • 827
  • 9
  • 23