How to Check Python Version in Linux, Mac, & Windows
Python is a popular programming language. Like many other programming languages, there can be several different versions organized by release date. Certain applications may require a specific version of Python.
In this tutorial, learn how to check the Python version on Windows, Linux, or macOS systems.
Access to a command-line/terminal window:
- Linux: Ctrl-Alt-T, Ctrl-Alt-F2
- Windows: Win+R > type powershell > Enter/OK
- MacOS: Finder > Applications > Utilities > Terminal
There are different versions of Python, but the two most popular ones are Python 2.7.x and Python 3.7.x. The x stands for the revision level and could change as new releases come out.
When looking at the version number, there are usually three digits to read:
- the major version
- the minor version
- the micro version
While major releases are not fully compatible, minor releases generally are. Version 3.6.1 should be compatible with 3.7.1 for example. The final digit signifies the latest patches and updates.
Python 2.7 and 3.7 are different applications. Software that’s written in one version often will not work correctly in another version. When using Python, it is essential to know which version an application requires, and which version you have.
Python 2 will stop publishing security updates and patches after 2020. They extended the deadline because of the large number of developers using Python 2.7. Python 3 includes a 2 to 3 utility that helps translate Python 2 code into Python 3.
How to Check Python Version in Linux
Most modern Linux distributions come with Python pre-installed.
To check the version installed, open a terminal window and entering the following:
How to Check Python Version in Windows
Most out-of-the-box Windows installations do not come with Python pre-installed. However, it is always a good idea to check.
Open Windows Powershell, and enter the following:
If you have Python installed, it will report the version number.
Alternately, use the Windows Search function to see which version of Python you have:
Press the Windows key to start a search, then type Python. The system will return any results that match. Most likely a match will show something similar to:
This defines which major and minor revision (3.x or 2.x) you are using.
How to Check Python Version in MacOS
If using a MacOS, check the Python version by entering the following command in the terminal:
The system will report the version.
Note: In some cases, this will return a screen full of information. If that happens, just scan through the file locations for the word python with a number after it. That number is the version.
Checking a System with Multiple Versions of Python
Python2 and Python3 are different programs. Many programs upgrade from the older version to the newer one. However, Python 2.7.x installations can be run separately from the Python 3.7.x version on the same system.
Python 3 is not entirely backward compatible.
To check for Python 2.7.x:
To check the version of Python 3 software:
Most systems differentiate Python 2 as python and Python 3 as python3. If you do not have Python 2, your system may use the python command in place of python3 .
Note: Python does not have a built-in upgrade system. You’ll need to download the latest version and install it.
How to Check Python Version in Script
When writing an application, it is helpful to have the software check the version of Python before it runs to prevent crashes and incompatibilities.
Use the following code snippet to check for the correct version of Python:
When this script runs, it will test to see if Python 3.6 is installed on the system. If not, it will send a notification and displays the current Python version.
Note: One of the common issues in working with Python and datasets is missing data. Learn how to handle missing data in Python.
You should now have a solid understanding of how to check for the version of Python installed in several different operating systems. Python is a powerful programming language, thus it’s important to understand its different versions.
If you want to learn how to upgrade Python to a newer version on Wondows, macOs, and Linux, check our article how to upgrade Python to 3.9.
Как узнать используемую версию Питона?
Пользователи могут просто пользоваться различными программами, однако, немаловажное значение имеет версия приложения. Это касается, в основном, ПО для программирования. Если у человека старая версия – будет сложновато проигрывать те или иные скрипты, ведь станут возникать неполадки разного типа. Поэтому, важно убедиться в том, новый релиз установлен или же Python устарел. В этом материале будет предоставлена инструкция для проверки.
Проверка версии Python
Существует несколько способов проверки версии установленного языка Python. Однако, легче всего это сделать с помощью Командной строки или Терминала (Windows и macOS/Linux соответственно). Для этого нужно лишь ввести одну команду, которая имеет несколько разновидностей (нет разницы в результате):
- python -version
- python -v
- python -vv
Ничего более не будет использоваться для получения требуемых данных. Человек должен увидеть в рабочем поле только подобную строку информации: «Python 3.7.2». После этого не нужно закрывать Командную строку/Терминал или открывать дополнительную программу для выхода – достаточно продолжать свои дела(если таковые есть).
Как узнать версию Python из скрипта?
Хоть проще всего воспользоваться стандартными средствами для определения версии Python, но можно и в самом скрипте узнать о том, какая версия используется для выполнения. Для этого существует масса команд с одной ролью. Но ответы несколько различаются:
- importsyssys.version– это позволит узнать не только версию, но и время проверки. Пример ответа: ‘3.7.2 (tags/v3.7.2:9a3ffc0492, Jun 7, 2021,12:18:09) [MSC v. 1916 64 bit (AMD64)]’
- sys.version_info– в первых 3 строках находятся цифры для определения версии. Ответ примерно такой: sys.version_info(major=3, minor=7, micro=2, releaselevel=’final’, serial=0)
- importplatform или же platform.python_version() – ответ составляет лишь версию, к примеру: ‘3.7.2’
- platform.python_version_turple() – опять же, все 3 цифры обозначают версию Python. К примеру, выглядит это так: (‘3’, ‘7’, ‘2’)
Получается, что можно найти несколькими способами нужную информацию о Python. Ничего сложного в этом нет, а потому – возможно произвести эту операцию легко: как с помощью стандартных программ, так и при использовании самих скриптов языка.
Как проверить версию Python в скриптах
В различных обстоятельствах нам необходимо знать версию Python, а точнее — версию интерпретатора Python, выполняющего файл скрипта Python.
Please enable JavaScript
sys.version способ проверки версии Python
Информация об этой версии может быть получена из sys.version в модуле sys .
или на Python 3.x
sys.version_info способ проверки версии Python
sys.version возвращает строку, содержащую информацию о читаемой человеком версии текущего интерпретатора Python. Но такая информация как major release number и micro release number требует дополнительной обработки для дальнейшего использования в кодах.
sys.version_info легко решает эту проблему, возвращая информацию о версии в виде именованного кортежа. Возвращается информация о версии,
Вы можете сравнить текущую версию со справочной просто используя операторы > , >= , == , <= или < .
Мы могли бы добавить в скрипты assert , чтобы убедиться, что скрипт работает с требованием минимальной версии на Python.
Это вызовет AssertionError , если интерпретатор не соответствует требованию версии.
Метод platform.python_version() для проверки версии на Python
python_version() в модуле platform возвращает версию Python в виде строки major.minor.patchlevel .
Или аналогично sys.version_info , platform также имеет метод возврата Python версии в виде кортежа (major, minor, patchlevel) из строк — python_version_tuple() .
six модульный метод проверки версии Python
Если вам нужно только проверить, является ли версия Python 2.x или Python 3.x, вы можете использовать six модуль для выполнения этой работы.
sys — System-specific parameters and functions¶
This module provides access to some variables used or maintained by the interpreter and to functions that interact strongly with the interpreter. It is always available.
On POSIX systems where Python was built with the standard configure script, this contains the ABI flags as specified by PEP 3149.
Changed in version 3.8: Default flags became an empty string ( m flag for pymalloc has been removed).
New in version 3.2.
Append the callable hook to the list of active auditing hooks for the current (sub)interpreter.
When an auditing event is raised through the sys.audit() function, each hook will be called in the order it was added with the event name and the tuple of arguments. Native hooks added by PySys_AddAuditHook() are called first, followed by hooks added in the current (sub)interpreter. Hooks can then log the event, raise an exception to abort the operation, or terminate the process entirely.
Note that audit hooks are primarily for collecting information about internal or otherwise unobservable actions, whether by Python or libraries written in Python. They are not suitable for implementing a “sandbox”. In particular, malicious code can trivially disable or bypass hooks added using this function. At a minimum, any security-sensitive hooks must be added using the C API PySys_AddAuditHook() before initialising the runtime, and any modules allowing arbitrary memory modification (such as ctypes ) should be completely removed or closely monitored.
Calling sys.addaudithook() will itself raise an auditing event named sys.addaudithook with no arguments. If any existing hooks raise an exception derived from RuntimeError , the new hook will not be added and the exception suppressed. As a result, callers cannot assume that their hook has been added unless they control all existing hooks.
See the audit events table for all events raised by CPython, and PEP 578 for the original design discussion.
New in version 3.8.
Changed in version 3.8.1: Exceptions derived from Exception but not RuntimeError are no longer suppressed.
CPython implementation detail: When tracing is enabled (see settrace() ), Python hooks are only traced if the callable has a __cantrace__ member that is set to a true value. Otherwise, trace functions will skip the hook.
The list of command line arguments passed to a Python script. argv[0] is the script name (it is operating system dependent whether this is a full pathname or not). If the command was executed using the -c command line option to the interpreter, argv[0] is set to the string ‘-c’ . If no script name was passed to the Python interpreter, argv[0] is the empty string.
To loop over the standard input, or the list of files given on the command line, see the fileinput module.
On Unix, command line arguments are passed by bytes from OS. Python decodes them with filesystem encoding and “surrogateescape” error handler. When you need original bytes, you can get it by [os.fsencode(arg) for arg in sys.argv] .
Raise an auditing event and trigger any active auditing hooks. event is a string identifying the event, and args may contain optional arguments with more information about the event. The number and types of arguments for a given event are considered a public and stable API and should not be modified between releases.
For example, one auditing event is named os.chdir . This event has one argument called path that will contain the requested new working directory.
sys.audit() will call the existing auditing hooks, passing the event name and arguments, and will re-raise the first exception from any hook. In general, if an exception is raised, it should not be handled and the process should be terminated as quickly as possible. This allows hook implementations to decide how to respond to particular events: they can merely log the event or abort the operation by raising an exception.
Hooks are added using the sys.addaudithook() or PySys_AddAuditHook() functions.
The native equivalent of this function is PySys_Audit() . Using the native function is preferred when possible.
See the audit events table for all events raised by CPython.
New in version 3.8.
Set during Python startup, before site.py is run, to the same value as exec_prefix . If not running in a virtual environment , the values will stay the same; if site.py finds that a virtual environment is in use, the values of prefix and exec_prefix will be changed to point to the virtual environment, whereas base_prefix and base_exec_prefix will remain pointing to the base Python installation (the one which the virtual environment was created from).
New in version 3.3.
Set during Python startup, before site.py is run, to the same value as prefix . If not running in a virtual environment , the values will stay the same; if site.py finds that a virtual environment is in use, the values of prefix and exec_prefix will be changed to point to the virtual environment, whereas base_prefix and base_exec_prefix will remain pointing to the base Python installation (the one which the virtual environment was created from).
New in version 3.3.
An indicator of the native byte order. This will have the value ‘big’ on big-endian (most-significant byte first) platforms, and ‘little’ on little-endian (least-significant byte first) platforms.
A tuple of strings containing the names of all modules that are compiled into this Python interpreter. (This information is not available in any other way — modules.keys() only lists the imported modules.)
sys. call_tracing ( func , args ) ¶
Call func(*args) , while tracing is enabled. The tracing state is saved, and restored afterwards. This is intended to be called from a debugger from a checkpoint, to recursively debug some other code.
A string containing the copyright pertaining to the Python interpreter.
Clear the internal type cache. The type cache is used to speed up attribute and method lookups. Use the function only to drop unnecessary references during reference leak debugging.
This function should be used for internal and specialized purposes only.
Return a dictionary mapping each thread’s identifier to the topmost stack frame currently active in that thread at the time the function is called. Note that functions in the traceback module can build the call stack given such a frame.
This is most useful for debugging deadlock: this function does not require the deadlocked threads’ cooperation, and such threads’ call stacks are frozen for as long as they remain deadlocked. The frame returned for a non-deadlocked thread may bear no relationship to that thread’s current activity by the time calling code examines the frame.
This function should be used for internal and specialized purposes only.
Raises an auditing event sys._current_frames with no arguments.
Return a dictionary mapping each thread’s identifier to the topmost exception currently active in that thread at the time the function is called. If a thread is not currently handling an exception, it is not included in the result dictionary.
This is most useful for statistical profiling.
This function should be used for internal and specialized purposes only.
Raises an auditing event sys._current_exceptions with no arguments.
This hook function is called by built-in breakpoint() . By default, it drops you into the pdb debugger, but it can be set to any other function so that you can choose which debugger gets used.
The signature of this function is dependent on what it calls. For example, the default binding (e.g. pdb.set_trace() ) expects no arguments, but you might bind it to a function that expects additional arguments (positional and/or keyword). The built-in breakpoint() function passes its *args and **kws straight through. Whatever breakpointhooks() returns is returned from breakpoint() .
The default implementation first consults the environment variable PYTHONBREAKPOINT . If that is set to "0" then this function returns immediately; i.e. it is a no-op. If the environment variable is not set, or is set to the empty string, pdb.set_trace() is called. Otherwise this variable should name a function to run, using Python’s dotted-import nomenclature, e.g. package.subpackage.module.function . In this case, package.subpackage.module would be imported and the resulting module must have a callable named function() . This is run, passing in *args and **kws , and whatever function() returns, sys.breakpointhook() returns to the built-in breakpoint() function.
Note that if anything goes wrong while importing the callable named by PYTHONBREAKPOINT , a RuntimeWarning is reported and the breakpoint is ignored.
Also note that if sys.breakpointhook() is overridden programmatically, PYTHONBREAKPOINT is not consulted.
New in version 3.7.
Print low-level information to stderr about the state of CPython’s memory allocator.
If Python is built in debug mode ( configure —with-pydebug option ), it also performs some expensive internal consistency checks.
New in version 3.3.
CPython implementation detail: This function is specific to CPython. The exact output format is not defined here, and may change.
Integer specifying the handle of the Python DLL.
If value is not None , this function prints repr(value) to sys.stdout , and saves value in builtins._ . If repr(value) is not encodable to sys.stdout.encoding with sys.stdout.errors error handler (which is probably ‘strict’ ), encode it to sys.stdout.encoding with ‘backslashreplace’ error handler.
sys.displayhook is called on the result of evaluating an expression entered in an interactive Python session. The display of these values can be customized by assigning another one-argument function to sys.displayhook .
Changed in version 3.2: Use ‘backslashreplace’ error handler on UnicodeEncodeError .
If this is true, Python won’t try to write .pyc files on the import of source modules. This value is initially set to True or False depending on the -B command line option and the PYTHONDONTWRITEBYTECODE environment variable, but you can set it yourself to control bytecode file generation.
A named tuple holding information about the environment on the wasm32-emscripten platform. The named tuple is provisional and may change in the future.
Emscripten version as tuple of ints (major, minor, micro), e.g. (3, 1, 8) .
Runtime string, e.g. browser user agent, ‘Node.js v14.18.2’ , or ‘UNKNOWN’ .
True if Python is compiled with Emscripten pthreads support.
True if Python is compiled with shared memory support.
New in version 3.11.
If this is set (not None ), Python will write bytecode-cache .pyc files to (and read them from) a parallel directory tree rooted at this directory, rather than from __pycache__ directories in the source code tree. Any __pycache__ directories in the source code tree will be ignored and new .pyc files written within the pycache prefix. Thus if you use compileall as a pre-build step, you must ensure you run it with the same pycache prefix (if any) that you will use at runtime.
A relative path is interpreted relative to the current working directory.
This value is initially set based on the value of the -X pycache_prefix=PATH command-line option or the PYTHONPYCACHEPREFIX environment variable (command-line takes precedence). If neither are set, it is None .
New in version 3.8.
This function prints out a given traceback and exception to sys.stderr .
When an exception is raised and uncaught, the interpreter calls sys.excepthook with three arguments, the exception class, exception instance, and a traceback object. In an interactive session this happens just before control is returned to the prompt; in a Python program this happens just before the program exits. The handling of such top-level exceptions can be customized by assigning another three-argument function to sys.excepthook .
Raise an auditing event sys.excepthook with arguments hook , type , value , traceback when an uncaught exception occurs. If no hook has been set, hook may be None . If any hook raises an exception derived from RuntimeError the call to the hook will be suppressed. Otherwise, the audit hook exception will be reported as unraisable and sys.excepthook will be called.
The sys.unraisablehook() function handles unraisable exceptions and the threading.excepthook() function handles exception raised by threading.Thread.run() .
These objects contain the original values of breakpointhook , displayhook , excepthook , and unraisablehook at the start of the program. They are saved so that breakpointhook , displayhook and excepthook , unraisablehook can be restored in case they happen to get replaced with broken or alternative objects.
New in version 3.7: __breakpointhook__
New in version 3.8: __unraisablehook__
This function, when called while an exception handler is executing (such as an except or except* clause), returns the exception instance that was caught by this handler. When exception handlers are nested within one another, only the exception handled by the innermost handler is accessible.
If no exception handler is executing, this function returns None .
New in version 3.11.
This function returns the old-style representation of the handled exception. If an exception e is currently handled (so exception() would return e ), exc_info() returns the tuple (type(e), e, e.__traceback__) . That is, a tuple containing the type of the exception (a subclass of BaseException ), the exception itself, and a traceback object which typically encapsulates the call stack at the point where the exception last occurred.
If no exception is being handled anywhere on the stack, this function return a tuple containing three None values.
Changed in version 3.11: The type and traceback fields are now derived from the value (the exception instance), so when an exception is modified while it is being handled, the changes are reflected in the results of subsequent calls to exc_info() .
A string giving the site-specific directory prefix where the platform-dependent Python files are installed; by default, this is also ‘/usr/local’ . This can be set at build time with the —exec-prefix argument to the configure script. Specifically, all configuration files (e.g. the pyconfig.h header file) are installed in the directory exec_prefix /lib/python X.Y /config , and shared library modules are installed in exec_prefix /lib/python X.Y /lib-dynload , where X.Y is the version number of Python, for example 3.2 .
If a virtual environment is in effect, this value will be changed in site.py to point to the virtual environment. The value for the Python installation will still be available, via base_exec_prefix .
A string giving the absolute path of the executable binary for the Python interpreter, on systems where this makes sense. If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None .
Raise a SystemExit exception, signaling an intention to exit the interpreter.
The optional argument arg can be an integer giving the exit status (defaulting to zero), or another type of object. If it is an integer, zero is considered “successful termination” and any nonzero value is considered “abnormal termination” by shells and the like. Most systems require it to be in the range 0–127, and produce undefined results otherwise. Some systems have a convention for assigning specific meanings to specific exit codes, but these are generally underdeveloped; Unix programs generally use 2 for command line syntax errors and 1 for all other kind of errors. If another type of object is passed, None is equivalent to passing zero, and any other object is printed to stderr and results in an exit code of 1. In particular, sys.exit("some error message") is a quick way to exit a program when an error occurs.
Since exit() ultimately “only” raises an exception, it will only exit the process when called from the main thread, and the exception is not intercepted. Cleanup actions specified by finally clauses of try statements are honored, and it is possible to intercept the exit attempt at an outer level.
Changed in version 3.6: If an error occurs in the cleanup after the Python interpreter has caught SystemExit (such as an error flushing buffered data in the standard streams), the exit status is changed to 120.
The named tuple flags exposes the status of command line flags. The attributes are read only.