6

Similarly to the __author__ or __version__ top level module variables, is there any convention for specifying supported Python versions for a Python source file?

My usecase is a project that has some scripts that need to be compatible with Python 2.4. I would like to note that fact in them in some universally recognizable way.

I am not asking how to require a minimal Python version during execution. My problem is that developers may accidentally use feature which is not compatible with python version this particular script needs to support. PyCharm can warn about Python incompatibilities. It would be great if it could pick up this annotation and configure the warning on a per-file basis.

Community
  • 1
  • 1
user7610
  • 25,267
  • 15
  • 124
  • 150
  • You can do something like `import sys` and then `sys.version[0:3]` will `x.y`, so you can test against that. – Eli Sadoff Nov 17 '16 at 21:06
  • Take a look at the answers on [this question](http://stackoverflow.com/questions/1093322/how-do-i-check-what-version-of-python-is-running-my-script) – Jake Conway Nov 17 '16 at 21:07
  • 1
    Just to clarify: Problem I want to prevent is not that somebody runs the script with wrong version. My problem is that developers may accidentally use feature which is not compatible with python version this particular script needs to support. – user7610 Nov 17 '16 at 21:09

1 Answers1

2

There's no convention that I know of for specifying supported Python versions in a Python source file. If you're making a Python library and distributing it via PyPI (and pip), you can add package metadata that says which versions of Python it's compatible with.

For example, for my scandir module, you can see on PyPI that it's (currently) marked as compatible with Python 2.6, 2.7, and 3.2-3.5. That metadata lives in the classifiers keyword in the package's setup.py:

setup(
    name='scandir',
    # ...
    classifiers=[
        'Programming Language :: Python :: 2',
        'Programming Language :: Python :: 2.6',
        'Programming Language :: Python :: 2.7',
        'Programming Language :: Python :: 3',
        'Programming Language :: Python :: 3.2',
        'Programming Language :: Python :: 3.3',
        'Programming Language :: Python :: 3.4',
        'Programming Language :: Python :: 3.5',
        # ...
    ]
)

If you're not releasing this as a PyPI package, one alternative might be to produce a warning when the module is imported on an older version of Python, saying that the FizzBuzz feature isn't supported on this version of Python.

import sys, warnings
if sys.version_info < (3, 5):
    warnings.warn('The FizzBuzz feature is only supported on Python 3.5+')

All that said, personally I'd just keep it simple: document that feature X is only supported on Python 3.5+ and then if someone tries to use that feature on an older version, just let it fail.

Ben Hoyt
  • 10,694
  • 5
  • 60
  • 84
  • The classifiers are useful for documentation purposes: They tell about which Python versions _should_ work (while this is not verified in any way, IIRC). They don't, however, prevent e.g. pip from picking a version which is not supporting your actual interpreter anymore; e.g. for Python 2.7, [kitconcept.dsgvo](https://pypi.org/project/kitconcept.dsgvo/) 2.0.0 was picked, while 1.3.0 is the last 2.7-compatible release. – Tobias Oct 01 '21 at 15:34