Синтаксис:
raise <expression> # Основной способ вызвать ошибку: raise Exception('Какой-то текст')
Описание:
Инструкция raise
позволяет программисту:
- Принудительно вызвать одно исключение в любое время и в любом месте кода.
- Повторно вызвать исключение, которое было перехвачено
try/except
, чтобы его можно было обработать дальше по стеку вызовов. - Создавать исключения, когда выполнение программы бессмысленно или не может продолжаться (например при вводе данных с клавиатуры).
Инструкция raise
позволяет программисту принудительно вызвать указанное исключение. Например:
>>> raise NameError('HiThere') # Traceback (most recent call last): # File "<stdin>", line 1, in <module> # NameError: HiThere
В общем случае инструкция raise
повторно вызывает последнее исключение, которое было активным в текущей области видимости. Если нужно определить, было ли вызвано исключение, но не обрабатывать его, более простая форма инструкции raise
позволяет повторно вызвать исключение:
try: raise NameError('HiThere') except NameError: print('Исключение пролетело незаметно!') # Еще какие-то действия, например запись в журнал логов ... # затем повторно вызываем `NameError` raise # Исключение пролетело незаметно! # Traceback (most recent call last): # File "<stdin>", line 2, in <module> # NameError: HiThere
Если в текущей области видимости нет активного исключения, то в месте, где указана инструкция raise
, без указания <expression>
, возникает исключение RuntimeError
, указывающее на ошибку.
>>> raise # Traceback (most recent call last): # File "<stdin>", line 1, in <module> # RuntimeError: No active exception to reraise
В противном случае raise
вычисляет первое выражение <expression>
как объект исключения. Он должен быть подклассом BaseException
, например Exception
или один из его подклассов. Если передается класс исключения, он будет неявно создан путем вызова его конструктора без аргументов.
# сокращение для 'raise ValueError()' >>> raise ValueError # Traceback (most recent call last): # File "<stdin>", line 1, in <module> # ValueError
При возникновении исключения объект traceback
обычно создается автоматически и присоединяется к нему в качестве атрибута __traceback__
. Следовательно можно создать исключение путем raise
и установить в него свой собственный traceback
за один шаг, используя метод BaseException.with_traceback()
, например:
try: ... except SomeException: # Получаем трассировку tb = sys.exception().__traceback__ # передаем трассировку raise AnyException(...).with_traceback(tb)
Инструкция raise
и цепочка исключений.
Если внутри раздела except
(конструкции try/except
) появляется НЕперехваченное исключение (например с помощью raise
), то к нему будет привязано исключение, которое было перехвачено инструкцией except
в качестве атрибута __cause__
, и оба будут выведены в сообщении об ошибке:
try: open("database.sqlite") except OSError: raise RuntimeError("не удается обработать ошибку") # Traceback (most recent call last): # File "<stdin>", line 2, in <module> # FileNotFoundError: [Errno 2] No such file or directory: 'database.sqlite' # During handling of the above exception, another exception occurred: # Traceback (most recent call last): # File "<stdin>", line 4, in <module> # RuntimeError: не удается обработать ошибку
Подобный механизм работает неявно, если исключение вызывается внутри обработчика исключений (внутри предложения try
) или внутри предложения finally
, то предыдущее исключение присоединяется в качестве атрибута __context__
нового исключения:
Оператор raise
допускает необязательное предложение from
, которое используется для указания того, что одно исключение является прямым следствием другого:
def func(): raise ConnectionError try: func() except ConnectionError as exc: raise RuntimeError('Не удалось открыть базу данных') from exc # Traceback (most recent call last): # File "<stdin>", line 2, in <module> # File "<stdin>", line 2, in func # ConnectionError # The above exception was the direct cause of the following exception: # Traceback (most recent call last): # File "<stdin>", line 4, in <module> # RuntimeError: Не удалось открыть базу данных
Цепочка исключений может быть явно подавлена/отключена путем указания значения None
в предложении from
:
try: a = 1 / 0 except Exception as exc: raise RuntimeError("Случилось что-то плохое") from None # Traceback (most recent call last): # File "<stdin>", line 4, in <module> # RuntimeError: Случилось что-то плохое
Пример вызова исключения, когда выполнение программы бессмысленно или не может продолжаться.
# например, поступили данные с клавиатуры s = 'apple' try: # пытаемся преобразовать данные num = int(s) except ValueError: raise ValueError("Строка не может быть преобразована в целое число") from None # Traceback (most recent call last): # File "<stdin>", line 5, in <module> # ValueError: Строка не может быть преобразована в целое число
How do I manually throw/raise an exception in Python?
Use the most specific Exception constructor that semantically fits your issue.
Be specific in your message, e.g.:
raise ValueError('A very specific bad thing happened.')
Don’t raise generic exceptions
Avoid raising a generic Exception
. To catch it, you’ll have to catch all other more specific exceptions that subclass it.
Problem 1: Hiding bugs
raise Exception('I know Python!') # Don't! If you catch, likely to hide bugs.
For example:
def demo_bad_catch():
try:
raise ValueError('Represents a hidden bug, do not catch this')
raise Exception('This is the exception you expect to handle')
except Exception as error:
print('Caught this error: ' + repr(error))
>>> demo_bad_catch()
Caught this error: ValueError('Represents a hidden bug, do not catch this',)
Problem 2: Won’t catch
And more specific catches won’t catch the general exception:
def demo_no_catch():
try:
raise Exception('general exceptions not caught by specific handling')
except ValueError as e:
print('we will not catch exception: Exception')
>>> demo_no_catch()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in demo_no_catch
Exception: general exceptions not caught by specific handling
Best Practices: raise
statement
Instead, use the most specific Exception constructor that semantically fits your issue.
raise ValueError('A very specific bad thing happened')
which also handily allows an arbitrary number of arguments to be passed to the constructor:
raise ValueError('A very specific bad thing happened', 'foo', 'bar', 'baz')
These arguments are accessed by the args
attribute on the Exception
object. For example:
try:
some_code_that_may_raise_our_value_error()
except ValueError as err:
print(err.args)
prints
('message', 'foo', 'bar', 'baz')
In Python 2.5, an actual message
attribute was added to BaseException
in favor of encouraging users to subclass Exceptions and stop using args
, but the introduction of message
and the original deprecation of args has been retracted.
Best Practices: except
clause
When inside an except clause, you might want to, for example, log that a specific type of error happened, and then re-raise. The best way to do this while preserving the stack trace is to use a bare raise statement. For example:
logger = logging.getLogger(__name__)
try:
do_something_in_app_that_breaks_easily()
except AppError as error:
logger.error(error)
raise # just this!
# raise AppError # Don't do this, you'll lose the stack trace!
Don’t modify your errors… but if you insist.
You can preserve the stacktrace (and error value) with sys.exc_info()
, but this is way more error prone and has compatibility problems between Python 2 and 3, prefer to use a bare raise
to re-raise.
To explain — the sys.exc_info()
returns the type, value, and traceback.
type, value, traceback = sys.exc_info()
This is the syntax in Python 2 — note this is not compatible with Python 3:
raise AppError, error, sys.exc_info()[2] # avoid this.
# Equivalently, as error *is* the second object:
raise sys.exc_info()[0], sys.exc_info()[1], sys.exc_info()[2]
If you want to, you can modify what happens with your new raise — e.g. setting new args
for the instance:
def error():
raise ValueError('oops!')
def catch_error_modify_message():
try:
error()
except ValueError:
error_type, error_instance, traceback = sys.exc_info()
error_instance.args = (error_instance.args[0] + ' <modification>',)
raise error_type, error_instance, traceback
And we have preserved the whole traceback while modifying the args. Note that this is not a best practice and it is invalid syntax in Python 3 (making keeping compatibility much harder to work around).
>>> catch_error_modify_message()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 3, in catch_error_modify_message
File "<stdin>", line 2, in error
ValueError: oops! <modification>
In Python 3:
raise error.with_traceback(sys.exc_info()[2])
Again: avoid manually manipulating tracebacks. It’s less efficient and more error prone. And if you’re using threading and sys.exc_info
you may even get the wrong traceback (especially if you’re using exception handling for control flow — which I’d personally tend to avoid.)
Python 3, Exception chaining
In Python 3, you can chain Exceptions, which preserve tracebacks:
raise RuntimeError('specific message') from error
Be aware:
- this does allow changing the error type raised, and
- this is not compatible with Python 2.
Deprecated Methods:
These can easily hide and even get into production code. You want to raise an exception, and doing them will raise an exception, but not the one intended!
Valid in Python 2, but not in Python 3 is the following:
raise ValueError, 'message' # Don't do this, it's deprecated!
Only valid in much older versions of Python (2.4 and lower), you may still see people raising strings:
raise 'message' # really really wrong. don't do this.
In all modern versions, this will actually raise a TypeError
, because you’re not raising a BaseException
type. If you’re not checking for the right exception and don’t have a reviewer that’s aware of the issue, it could get into production.
Example Usage
I raise Exceptions to warn consumers of my API if they’re using it incorrectly:
def api_func(foo):
'''foo should be either 'baz' or 'bar'. returns something very useful.'''
if foo not in _ALLOWED_ARGS:
raise ValueError('{foo} wrong, use "baz" or "bar"'.format(foo=repr(foo)))
Create your own error types when apropos
«I want to make an error on purpose, so that it would go into the except»
You can create your own error types, if you want to indicate something specific is wrong with your application, just subclass the appropriate point in the exception hierarchy:
class MyAppLookupError(LookupError):
'''raise this when there's a lookup error for my app'''
and usage:
if important_key not in resource_dict and not ok_to_be_missing:
raise MyAppLookupError('resource is missing, and that is not ok.')
Python raise Keyword is used to raise exceptions or errors. The raise keyword raises an error and stops the control flow of the program. It is used to bring up the current exception in an exception handler so that it can be handled further up the call stack.
Syntax of the raise keyword :
raise {name_of_ the_ exception_class}
The basic way to raise an error is :
raise Exception(“user text”)
Example:
In the below code, we check if an integer is even or odd. if the integer is odd an exception is raised. a is a variable to which we assigned a number 5, as a is odd, then if loop checks if it’s an odd integer, if it’s an odd integer then an error is raised.
Input:
Python3
a
=
5
if
a
%
2
!
=
0
:
raise
Exception(
"The number shouldn't be an odd integer"
)
Output:
While raising an error we can also what kind of error we need to raise, and if necessary print out a text.
Syntax:
raise TypeError
Example:
In the below code, we tried changing the string ‘apple’ assigned to s to integer and wrote a try-except clause to raise the ValueError. the raise keyword raises a value error with the message “String can’t be changed into an integer”.
Input:
Python3
s
=
'apple'
try
:
num
=
int
(s)
except
ValueError:
raise
ValueError(
"String can't be changed into integer"
)
Output:
Raising an exception Without Specifying Exception Class
When we use the raise keyword, there’s no compulsion to give an exception class along with it. When we do not give any exception class name with the raise keyword, it reraises the exception that last occurred.
Example:
In the above code, we tried changing the string ‘apple’ to integer and wrote a try-except clause to raise the ValueError. The code is the same as before except that we don’t provide an exception class, it reraises the exception that was last occurred.
Input:
Python3
s
=
'apple'
try
:
num
=
int
(s)
except
:
raise
Output:
Advantages of the raise keyword:
- It helps us raise exceptions when we may run into situations where execution can’t proceed.
- It helps us reraise an exception that is caught.
- Raise allows us to throw one exception at any time.
- It is useful when we want to work with input validations.
Last Updated :
28 Nov, 2021
Like Article
Save Article
Мы можем принудительно вызвать исключение, используя ключевое слово повышение. Вот синтаксис для вызова метода «поднимать».
raise [Exception [, args [, traceback]]]
где, Исключением является название исключения; необязательный аргумент «args» представляет значение аргумента исключения.
Также необязательный аргумент traceback — это объект трассировки, используемый для исключения.
#raise_error.py try: i = int ( input ( "Enter a positive integer value: " ) ) if i <= 0: raise ValueError ( "This is not a positive number!!" ) except ValueError as e: print(e)
Если мы выполняем вышеуказанный скрипт на терминале следующим образом
$python raise_error.py Enter a positive integer: –6
После того, как мы ввели отрицательное число, отображается следующее:
This is not a positive number!!
Альтернативный пример кода
# Here there is no variable or argument passed with the raised exception import sys try: i = int ( input("Enter a positive integer value: ")) if i <= 0: raise ValueError#("This is not a positive number!!") except ValueError as e: print sys.exc_info()
вывод
Enter a positive integer value: -9 (<type 'exceptions.ValueError'>, ValueError(), <traceback object at 0x0000000003584EC8>)
Мы используем наиболее конкретный конструктор исключений, который соответствует нашей конкретной проблеме, а не генерирует общие исключения. Чтобы поймать наше конкретное исключение, нам нужно будет отловить все другие, более конкретные исключения, которые подклассируют его.
Мы должны вызывать конкретные исключения и обрабатывать те же конкретные исключения.
Чтобы поднять конкретные исключения, мы используем оператор поднятия следующим образом.
Пример
import sys try: f = float('Tutorialspoint') print f raise ValueError except Exception as err: print sys.exc_info()
вывод
Мы получаем следующий вывод
(<type 'exceptions.ValueError'>, ValueError('could not convert string to float: Tutorialspoint',), <traceback object at 0x0000000002E33748>)
Мы можем выдать ошибку даже с аргументами, как в следующем примере
Пример
try: raise ValueError('foo', 23) except ValueError, e: print e.args
вывод
Мы получаем следующий вывод
('foo', 23)
Обработка исключений
При выполнении заданий к параграфам вы, скорее всего, нередко сталкивались с возникновением различных ошибок. В этом параграфе мы изучим подход, который позволяет обрабатывать ошибки после их возникновения.
Напишем программу, которая будет считать обратные значения для целых чисел из заданного диапазона и выводить их в одну строку с разделителем ‘;’. Один из вариантов кода для решения этой задачи выглядит так:
print(";".join(str(1 / x) for x in range(int(input()), int(input()) + 1)))
Программа получилась в одну строчку за счёт использования списочных выражений. Однако при вводе диапазона чисел, включающего в себя 0 (например, от -1 до 1), программа выдаст следующую ошибку:
ZeroDivisionError: division by zero
В программе произошла ошибка «деление на ноль». Такая ошибка, возникающая при выполнении программы и останавливающая её работу, называется исключением.
Попробуем в нашей программе избавиться от возникновения исключения деления на ноль. Пусть при попадании 0 в диапазон чисел обработка не производится и выводится сообщение «Диапазон чисел содержит 0». Для этого нужно проверить до списочного выражения наличие нуля в диапазоне:
interval = range(int(input()), int(input()) + 1)
if 0 in interval:
print("Диапазон чисел содержит 0.")
else:
print(";".join(str(1 / x) for x in interval))
Теперь для диапазона, включающего в себя 0, например от -2 до 2, исключения ZeroDivisionError
не возникнет. Однако при вводе строки, которую невозможно преобразовать в целое число (например, «a»), будет вызвано другое исключение:
ValueError: invalid literal for int() with base 10: 'a'
Произошло исключение ValueError
. Для борьбы с этой ошибкой нам придётся проверить, что строка состоит только из цифр. Сделать это нужно до преобразования в число. Тогда наша программа будет выглядеть так:
start = input()
end = input()
# Метод lstrip("-"), удаляющий символы "-" в начале строки, нужен для учёта
# отрицательных чисел, иначе isdigit() вернёт для них False
if not (start.lstrip("-").isdigit() and end.lstrip("-").isdigit()):
print("
ввести два числа.")
else:
interval = range(int(start), int(end) + 1)
if 0 in interval:
print("Диапазон чисел содержит 0.")
else:
print(";".join(str(1 / x) for x in interval))
Теперь наша программа работает без ошибок и при вводе строк, которые нельзя преобразовать в целое число.
Подход, который был нами применён для предотвращения ошибок, называется Look Before You Leap (LBYL), или «Посмотри перед прыжком». В программе, реализующей такой подход, проверяются возможные условия возникновения ошибок до исполнения основного кода.
Подход LBYL имеет недостатки. Программу из примера стало сложнее читать из-за вложенного условного оператора. Проверка условия, что строка может быть преобразована в число, выглядит даже сложнее, чем списочное выражение. Вложенный условный оператор не решает поставленную задачу, а только лишь проверяет входные данные на корректность. Легко заметить, что решение основной задачи заняло меньше времени, чем составление условий проверки корректности входных данных.
Существует другой подход для работы с ошибками: Easier to Ask Forgiveness than Permission (EAFP), или «Проще попросить прощения, чем разрешения». В этом подходе сначала исполняется код, а в случае возникновения ошибок происходит их обработка. Подход EAFP реализован в Python в виде обработки исключений.
Исключения в Python являются классами ошибок. В Python есть много стандартных исключений. Они имеют определённую иерархию за счёт механизма наследования классов. В документации Python версии 3.10.8 приводится следующее дерево иерархии стандартных исключений:
BaseException +-- SystemExit +-- KeyboardInterrupt +-- GeneratorExit +-- Exception +-- StopIteration +-- StopAsyncIteration +-- ArithmeticError | +-- FloatingPointError | +-- OverflowError | +-- ZeroDivisionError +-- AssertionError +-- AttributeError +-- BufferError +-- EOFError +-- ImportError | +-- ModuleNotFoundError +-- LookupError | +-- IndexError | +-- KeyError +-- MemoryError +-- NameError | +-- UnboundLocalError +-- OSError | +-- BlockingIOError | +-- ChildProcessError | +-- ConnectionError | | +-- BrokenPipeError | | +-- ConnectionAbortedError | | +-- ConnectionRefusedError | | +-- ConnectionResetError | +-- FileExistsError | +-- FileNotFoundError | +-- InterruptedError | +-- IsADirectoryError | +-- NotADirectoryError | +-- PermissionError | +-- ProcessLookupError | +-- TimeoutError +-- ReferenceError +-- RuntimeError | +-- NotImplementedError | +-- RecursionError +-- SyntaxError | +-- IndentationError | +-- TabError +-- SystemError +-- TypeError +-- ValueError | +-- UnicodeError | +-- UnicodeDecodeError | +-- UnicodeEncodeError | +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- PendingDeprecationWarning +-- RuntimeWarning +-- SyntaxWarning +-- UserWarning +-- FutureWarning +-- ImportWarning +-- UnicodeWarning +-- BytesWarning +-- EncodingWarning +-- ResourceWarning
Для обработки исключения в Python используется следующий синтаксис:
try: <код , который может вызвать исключения при выполнении> except <классисключения_1>: <код обработки исключения> except <классисключения_2>: <код обработки исключения> ... else: <код выполняется, если не вызвано исключение в блоке try> finally: <код , который выполняется всегда>
Блок try
содержит код, в котором нужно обработать исключения, если они возникнут.
При возникновении исключения интерпретатор последовательно проверяет, в каком из блоков except
обрабатывается это исключение.
Исключение обрабатывается в первом блоке except
, обрабатывающем класс этого исключения или базовый класс возникшего исключения.
Необходимо учитывать иерархию исключений для определения порядка их обработки в блоках except
. Начинать обработку исключений следует с более узких классов исключений. Если начать с более широкого класса исключения, например Exception
, то всегда при возникновении исключения будет срабатывать первый блок except
.
Сравните два следующих примера. В первом порядок обработки исключений указан от производных классов к базовым, а во втором — наоборот.
Первый пример:
try:
print(1 / int(input()))
except ZeroDivisionError:
print("Ошибка деления на ноль.")
except ValueError:
print("Невозможно преобразовать строку в число.")
except Exception:
print("Неизвестная ошибка.")
При вводе значений «0» и «a» получим ожидаемый, соответствующий возникающим исключениям вывод:
Невозможно преобразовать строку в число.
и
Ошибка деления на ноль.
Второй пример:
try:
print(1 / int(input()))
except Exception:
print("Неизвестная ошибка.")
except ZeroDivisionError:
print("Ошибка деления на ноль.")
except ValueError:
print("Невозможно преобразовать строку в число.")
При вводе значений «0» и «a» получим в обоих случаях неинформативный вывод:
Неизвестная ошибка.
Необязательный блок else
выполняет код в случае, если в блоке try
не вызвано исключение. Добавим блок else
в пример для вывода сообщения об успешном выполнении операции:
try:
print(1 / int(input()))
except ZeroDivisionError:
print("Ошибка деления на ноль.")
except ValueError:
print("Невозможно преобразовать строку в число.")
except Exception:
print("Неизвестная ошибка.")
else:
print("Операция выполнена успешно.")
Теперь при вводе корректного значения, например «5», вывод программы будет следующим:
0.2 Операция выполнена успешно.
Блок finally
выполняется всегда, даже если возникло какое-то исключение, не учтённое в блоках except
, или код в этих блоках сам вызвал какое-либо исключение. Добавим в нашу программу вывод строки «Программа завершена» в конце программы даже при возникновении исключений:
try:
print(1 / int(input()))
except ZeroDivisionError:
print("Ошибка деления на ноль.")
except ValueError:
print("Невозможно преобразовать строку в число.")
except Exception:
print("Неизвестная ошибка.")
else:
print("Операция выполнена успешно.")
finally:
print("Программа завершена.")
Перепишем код, созданный с применением подхода LBYL, для первого примера из этого параграфа с использованием обработки исключений:
try:
print(";".join(str(1 / x) for x in range(int(input()), int(input()) + 1)))
except ZeroDivisionError:
print("Диапазон чисел содержит 0.")
except ValueError:
print("Необходимо ввести два числа.")
Теперь наша программа читается намного легче. При этом создание кода для обработки исключений не заняло много времени и не потребовало проверки сложных условий.
Исключения можно принудительно вызывать с помощью оператора raise
. Этот оператор имеет следующий синтаксис:
raise <класс исключения>(параметры)
В качестве параметра можно, например, передать строку с сообщением об ошибке.
Создание собственных исключений
В Python можно создавать свои собственные исключения. Синтаксис создания исключения такой же, как и у создания класса. При создании исключения его необходимо наследовать от какого-либо стандартного класса-исключения.
Напишем программу, которая выводит сумму списка целых чисел и вызывает исключение, если в списке чисел есть хотя бы одно чётное или отрицательное число. Создадим свои классы исключений:
- NumbersError — базовый класс исключения;
- EvenError — исключение, которое вызывается при наличии хотя бы одного чётного числа;
- NegativeError — исключение, которое вызывается при наличии хотя бы одного отрицательного числа.
class NumbersError(Exception):
pass
class EvenError(NumbersError):
pass
class NegativeError(NumbersError):
pass
def no_even(numbers):
if all(x % 2 != 0 for x in numbers):
return True
raise EvenError("В списке не должно быть чётных чисел")
def no_negative(numbers):
if all(x >= 0 for x in numbers):
return True
raise NegativeError("В списке не должно быть отрицательных чисел")
def main():
print("Введите числа в одну строку через пробел:")
try:
numbers = [int(x) for x in input().split()]
if no_negative(numbers) and no_even(numbers):
print(f"Сумма чисел равна: {sum(numbers)}.")
except NumbersError as e: # обращение к исключению как к объекту
print(f"Произошла ошибка: {e}.")
except Exception as e:
print(f"Произошла непредвиденная ошибка: {e}.")
if __name__ == "__main__":
main()
Модули
Обратите внимание: в программе основной код выделен в функцию main
. А код вне функций содержит только условный оператор и вызов функции main
при выполнении условия __name__ == "__main__"
. Это условие проверяет, запущен ли файл как самостоятельная программа или импортирован как модуль.
Любая программа, написанная на языке программирования Python, может быть импортирована как модуль в другую программу. В идеологии Python импортировать модуль — значит полностью его выполнить. Если основной код модуля содержит вызовы функций, ввод или вывод данных без использования указанного условия __name__ == "__main__"
, то произойдёт полноценный запуск программы. А это не всегда удобно, если из модуля нужна только отдельная функция или какой-либо класс.
При изучении модуля itertools
мы говорили о том, как импортировать модуль в программу. Покажем ещё раз два способа импорта на примере собственного модуля.
Для импорта модуля из файла, например example_module.py
, нужно указать его имя, если он находится в той же папке, что и импортирующая его программа:
import example_module
Если требуется отдельный компонент модуля, например функция или класс, то импорт можно осуществить так:
from example_module import some_function, ExampleClass
Обратите внимание: при втором способе импортированные объекты попадают в пространство имён новой программы. Это означает, что они будут объектами новой программы и в программе не должно быть других объектов с такими же именами.
Рассмотрим написанное выше на примере. Пусть имеется программа module_hello.py
, в которой находится функция hello(name)
, возвращающая строку приветствия пользователя по имени. В самой программе кроме функции присутствует вызов этой функции и печать результата её работы. Импортируем из модуля module_hello.py
функцию hello(name)
в другую программу program.py
и также используем для вывода приветствия пользователя.
Код программы module_hello.py
:
def hello(name):
return f"Привет, {name}!"
print(hello(input("Введите своё имя: ")))
Код программы program.py
:
from module_hello import hello
print(hello(input("Добрый день. Введите имя: ")))
При выполнении program.py
нас ожидает неожиданное действие. Программа сначала запросит имя пользователя, а затем сделает это ещё раз, но с приветствием из program.py
.
Введите своё имя: Андрей Привет, Андрей! Добрый день. Введите имя: Андрей Привет, Андрей!
Наша ошибка заключается в том, что программа module_hello.py
выполняется полностью, включая основной код с вызовом функции и выводом результата. Исправим программу module_hello.py
, добавив проверку, запущена программа или импортирована как модуль:
def hello(name):
return f"Привет, {name}!"
if __name__ == "__main__":
print(hello(input("Введите своё имя: ")))
Теперь при импорте модуля module_hello.py
код в теле условного оператора выполняться не будет. А основной код этой программы выполнится только при запуске файла как отдельной программы.
Для большего удобства обычно в теле указанного условного оператора вызывают функцию main()
, а основной код программы оформляют уже внутри этой функции.
Тогда наш модуль можно переписать так:
def hello(name):
return f"Привет, {name}!"
def main():
print(hello(input("Введите своё имя: ")))
if __name__ == "__main__":
main()
Обратите внимание: при импорте модуля мы можем с помощью символа *
указать, что необходимо импортировать все объекты. Например, так:
from some_module import *
Однако делать так крайне не рекомендуется, потому что все объекты модуля добавляются в пространство имён нашей программы, что может приводить к конфликтам.