Числа: целые, вещественные, комплексные

Переменные

Данные хранятся в ячейках памяти компьютера. Когда мы вводим число, оно помещается в какую-то ячейку памяти. Но как потом узнать, куда именно? Как впоследствии обращаться к этим данными? Нужно как-то запомнить, пометить соответствующую ячейку.

Раньше, при написании программ на машинном языке, обращение к ячейкам памяти осуществляли с помощью указания их регистров, т. е. конкретно сообщали, куда положить данные и откуда их взять. Однако с появлением ассемблеров при обращении к данным стали использовать словесные переменные, что куда удобней для человека.

Механизм связи между переменными и данными может различаться в зависимости от языка программирования и типов данных. Пока достаточно запомнить, что в программе данные связываются с каким-либо именем и в дальнейшем обращение к ним возможно по этому имени-переменной.

Слово «переменная» обозначает, что сущность может меняться, она непостоянна. Действительно, вы увидите это в дальнейшем, одна и та же переменная может быть связана сначала с одними данными, а потом – с другими. То есть ее значение может меняться, она переменчива.

В программе на языке Python, как и на большинстве других языков, связь между данными и переменными устанавливается с помощью знака =. Такая операция называется присваивание (также говорят «присвоение»). Например, выражение sq = 4 означает, что на объект, представляющий собой число 4, находящееся в определенной области памяти, теперь ссылается переменная sq, и обращаться к этому объекту следует по имени sq.

Имена переменных могут быть любыми. Однако есть несколько общих правил их написания:

1. Желательно давать переменным осмысленные имена, говорящие о назначении данных, на которые они ссылаются.

2. Имя переменной не должно совпадать с командами языка (зарезервированными ключевыми словами).

3. Имя переменной должно начинаться с буквы или символа подчеркивания (_), но не с цифры.

4. Имя переменной не должно содержать пробелы.

Чтобы узнать значение, на которое ссылается переменная, находясь в режиме интерпретатора, достаточно ее вызвать, т. е. написать имя и нажать Enter.

>>> sq = 4
>>> sq
4

Вот более сложный пример работы с переменными в интерактивном режиме:

>>> apples = 100
>>> eat_day = 5
>>> day = 7
>>> apples = apples - eat_day * day
>>> apples
65

Здесь фигурируют три переменные: apples, eat_day и day. Каждой из них присваивается свое значение. Выражение сложное. Сначала выполняется подвыражение, стоящее справа от знака равенства. После этого его результат присваивается переменной apples, в результате чего ее старое значение (100) теряется. В подвыражении вместо имен переменных на самом деле используются их значения, т. е. числа 100, 5 и 7.

Adding more concise syntax

One objection to this PEP is that having to explicitly write Literal
feels verbose. For example, instead of writing:

def foobar(arg1: Literal, arg2: Literal) -> None:
    pass

…it would be nice to instead write:

def foobar(arg1: 1, arg2: True) -> None:
    pass

Unfortunately, these abbreviations simply will not work with the
existing implementation of typing at runtime. For example, the
following snippet crashes when run using Python 3.7:

from typing import Tuple

# Supposed to accept tuple containing the literals 1 and 2
def foo(x: Tuple) -> None:
    pass

Running this yields the following exception:

TypeError: Tuple: each t must be a type. Got 1.

We don’t want users to have to memorize exactly when it’s ok to elide
Literal, so we require Literal to always be present.

A little more broadly, we feel overhauling the syntax of types in
Python is not within the scope of this PEP: it would be best to have
that discussion in a separate PEP, instead of attaching it to this one.
So, this PEP deliberately does not try and innovate Python’s type syntax.

Disallowing instantiation of parameterized types

Given that the proxy type which preserves __origin__ and
__args__ is mostly useful for runtime introspection purposes,
we might have disallowed instantiation of parameterized types.

In fact, forbidding instantiation of parameterized types is what the
typing module does today for types which parallel builtin
collections (instantiation of other parameterized types is allowed).

The original reason for this decision was to discourage spurious
parameterization which made object creation up to two orders of magnitude
slower compared to the special syntax available for those builtin
collections.

Преобразование строк

Строка – это последовательность из одного или больше символов (цифр, букв и других символов). Строки – очень распространённый тип данных в программировании. Существует много способов преобразования строк.

Преобразование чисел в строки

Чтобы конвертировать число в строку, используйте метод str(). Поместите число или переменную в круглые скобки.

Попробуйте преобразовать целое число, например:

Запустив метод str(12) в интерактивной оболочке Python (с помощью команды python), вы получите вывод:

Кавычки означают, что теперь 12 является строкой, а не числом.

Особенно полезно преобразовывать числа в строки, используя переменные. К примеру, можно отследить, сколько строк кода  в день пишет тот или иной пользователь. Если пользователь пишет больше 50 строк, программа отправит ему поощрительное сообщение.

Запустив этот код, вы получите ошибку:

Python не может склеивать строки с числами, потому нужно преобразовать значение lines в строку.

Теперь, запустив код, вы увидите:

Метод str() может преобразовать в строку и число с плавающей точкой. Поместите в круглые скобки число или переменную:

Попробуйте выполнить конкатенацию строки и преобразованного в строку числа:

Преобразование строк в числа

Строки можно преобразовать в числа с помощью методов int() и float()

Если в строке нет десятичных знаков, лучше преобразовать её в целое число. Для этого используется int().

Попробуйте расширить предыдущий пример кода, который отслеживает количество написанных строк. Пусть программа отслеживает, сколько строк пишет пользователь каждый день.

При запуске возникла ошибка, поскольку Python не может выполнить сложение строк. Преобразуйте строки в числа и попробуйте снова запустить программу:

Значение переменной lines_more – это число, в данном случае это 58.

Также можно преобразовать числа в предыдущем примере в числа с плавающей точкой. Для этого используйте метод float() вместо int().

К примеру, очки начисляются в десятичных значениях.

В данном случае оператор + склеивает две строки, а не складывает числа. Потому в результате получилось довольно странное значение.

Конвертируйте эти строки в числа с плавающей точкой, а затем выполните сложение.

Как видите, теперь программа возвращает ожидаемый результат.

Если вы попробуете преобразовать строку с десятичными значениями в целое число, вы получите ошибку:

Кортежи

Кортежи – это те же списки, только в круглых скобках. Они могут хранить произвольное число данных любого типа, но поддерживают меньший набор операций. Их главное отличие – неизменяемость. Кортежи обеспечивают целостность и сохранность объектов, именно поэтому их иногда используют вместо типа list в крупных программах.

В Python 3 тип данных tuple обладает двумя методами, которые есть у списков: .index() для извлечения индекса элемента и .count(), чтобы подсчитать количество одинаковых объектов:

• >>>my_tuple = (1, 2, 3, 4).
• >>>my_tuple.index(2) #на второй позиции стоит цифра 1.
• 1.
• >>>my_tuple.count(1) #покажет сколько единиц в последовательности.
• 1.

Это были основные встроенные типы данных в Python. Также есть дополнительные объекты, которые могут считаться базовыми. Например, множества или нестандартные числовые типы, такие как матрицы, векторы, числа с фиксированной точностью. Для работы с ними требуется серьезное погружение в принципы математики и конструкций Python.

The Final annotation

The typing.Final type qualifier is used to indicate that a
variable or attribute should not be reassigned, redefined, or overridden.

Final may be used in in one of several forms:

• With an explicit type, using the syntax Final. Example:

  ID: Final = 1
  

• With no type annotation. Example:

  ID: Final = 1
  

  The typechecker should apply its usual type inference mechanisms to
  determine the type of ID (here, likely, int). Note that unlike for
  generic classes this is not the same as Final.

• In class bodies and stub files you can omit the right hand side and just write
  ID: Final. If the right hand side is omitted, there must
  be an explicit type argument to Final.

• Finally, as self.id: Final = 1 (also optionally with a type in
  square brackets). This is allowed only in __init__ methods, so
  that the final instance attribute is assigned only once when an
  instance is created.

The two main rules for defining a final name are:

• There can be at most one final declaration per module or class for
  a given attribute. There can’t be separate class-level and instance-level
  constants with the same name.
• There must be exactly one assignment to a final name.

This means a type checker should prevent further assignments to final
names in type-checked code:

from typing import Final

RATE: Final = 3000

class Base:
    DEFAULT_ID: Final = 0

RATE = 300  # Error: can't assign to final attribute
Base.DEFAULT_ID = 1  # Error: can't override a final attribute

Note that a type checker need not allow Final declarations inside loops
since the runtime will see multiple assignments to the same variable in
subsequent iterations.

Additionally, a type checker should prevent final attributes from
being overridden in a subclass:

from typing import Final

class Window:
    BORDER_WIDTH: Final = 2.5
    ...

class ListView(Window):
    BORDER_WIDTH = 3  # Error: can't override a final attribute

A final attribute declared in a class body without an initializer must
be initialized in the __init__ method (except in stub files):

class ImmutablePoint:
    x: Final
    y: Final  # Error: final attribute without an initializer

    def __init__(self) -> None:
        self.x = 1  # Good

Type checkers should infer a final attribute that is initialized in
a class body as being a class variable. Variables should not be annotated
with both ClassVar and Final.

Final may only be used as the outermost type in assignments or variable
annotations. Using it in any other position is an error. In particular,
Final can’t be used in annotations for function arguments:

x: List] = []  # Error!

def fun(x: Final]) ->  None:  # Error!
    ...

Note that declaring a name as final only guarantees that the name will
not be re-bound to another value, but does not make the value
immutable. Immutable ABCs and containers may be used in combination
with Final to prevent mutating such values:

x: Final = 
x.append('c')  # OK

y: Final] = 
y.append('x')  # Error: "Sequence" has no attribute "append"
z: Final = ('a', 'b')  # Also works

Type checkers should treat uses of a final name that was initialized
with a literal as if it was replaced by the literal. For example, the
following should be allowed:

from typing import NamedTuple, Final

X: Final = "x"
Y: Final = "y"
N = NamedTuple("N", )

Callback protocols

Protocols can be used to define flexible callback types that are hard
(or even impossible) to express using the Callable syntax
specified by PEP 484, such as variadic, overloaded, and complex generic
callbacks. They can be defined as protocols with a __call__ member:

from typing import Optional, List, Protocol

class Combiner(Protocol):
    def __call__(self, *vals: bytes,
                 maxlen: Optional = None) -> List: ...

def good_cb(*vals: bytes, maxlen: Optional = None) -> List:
    ...
def bad_cb(*vals: bytes, maxitems: Optional) -> List:
    ...

comb: Combiner = good_cb  # OK
comb = bad_cb  # Error! Argument 2 has incompatible type because of
               # different name and kind in the callback

Изменяемые и неизменяемые данные

Все типы данных в Python относятся к одной из 2-х категорий: изменяемые
(mutable) и неизменяемые
(unmutable).

Во всех русскоязычных переводах используется терминология
«изменяемый-неизменяемый». Это не самый удачный вариант, так как он
вносит неоднозначность, ассоциируясь с некоей константностью. Термины
«мутирующий-немутирующий» были бы уместнее и точнее отображали бы суть
происходящего: может ли объект этого типа изменять свою
структурность? Например: строка
— это неизменяемый тип,
так как в Python нельзя, в отличие от C/C++ изменить некоторый
одиночный символ в строке, например, через
, не говоря уже о том,
чтобы вставить символ внутрь строки. Но можно сделать
и
получить в результате, требуемую строку
, только это будет
совершенно другая строка, размещённая по совершенно
другому адресу в памяти, а —
переустановленная ссылка на эту новую строку. Но изменить строку или
её длину (её структурность) по текущей ссылке — невозможно. В этом и
состоит неизменяемость объекта — это не константность, так как его
значение можно изменить, но это будет уже ссылка
на другой объект с этим новым значением.

Многие из предопределённых типов данных Python — это типы неизменяемых
объектов: числовые данные (,
,
), символьные строки
(), кортежи
(). Другие типы определены как
изменяемые: списки (), множества
(), словари
()

Вновь определяемые пользователем
типы (классы) могут быть определены как неизменяемые или изменяемые.
Изменяемость объектов определённого типа является принципиально важной
характеристикой, определяющей, может ли объект такого типа выступать в
качестве ключа для словарей () или нет,
как будет показано в следующем разделе

Множественное присваивание переменной

Python позволяет присваивать одно значение нескольким переменным одновременно. Таким образом, вы можете инициализировать несколько переменных, а позже переназначить их.

Например, можно задать переменным x, y и z значение 0.

Теперь все три переменные имеют одинаковое значение и принадлежат к одной области памяти.

Python также позволяет присваивать несколько значений нескольким переменным в рамках одной строки. Например:

Как видите, переменной j было присвоено значение 8host, переменной k 1.05, l – 16.

Эта функция позволяет сократить код, и при этом сохранить его читабельность.

Локальная область видимости

Локальная область видимости наиболее часто используется в Python. Когда мы создаем переменную в блоке кода, она будет разрешена при помощи ближайшей области видимости, или областей. Группирование всех этих областей известно как среда блоков кода. Другими словами, все назначения выполняются в локальной области по умолчанию. Если вам нужно что-то другое, тогда вам нужно настроить свою переменную на глобальную или нелокальную область, которые мы рассмотрим немного позже. Сейчас мы создадим простой пример, используя интерпретатор Python, в котором демонстрируется назначение локальной области видимости.

Python

x = 10

def my_func(a, b):
print(x)
print(z)

my_func(1, 2)

1 2 3 4 5 6 7

x=10 defmy_func(a,b) print(x) print(z) my_func(1,2)

Результат

Python

10
Traceback (most recent call last):
File «<pyshell#19>», line 1, in <module>
my_func(1, 2)
File «<pyshell#18>», line 3, in my_func
print(z)
NameError: name ‘z’ is not defined

1 2 3 4 5 6 7

10 Traceback(most recent call last) File»<pyshell#19>»,line1,in<module> my_func(1,2) File»<pyshell#18>»,line3,inmy_func print(z) NameErrorname’z’isnotdefined

Здесь мы создаем переменную х и очень простую функцию, которая принимает два аргумента. Далее она выводит х и z

Обратите внимание на то, что мы не определили z, так что когда мы вызываем функцию, мы получаем ошибку NameError. Это происходит в связи с тем, что z не определена, или находится вне области видимости

Если вы определите z перед вызовом функции, тогда она будет найдена и ошибка NameError не возникнет. Ошибка NameError также возникает при попытке получения доступа к переменной, которая находится только внутри функции:

Python

def my_func(a, b):
i = 2
print(x)

if __name__ == ‘__main__’:
x = 10
my_func(1, 2)
print(i)

1 2 3 4 5 6 7 8 9

defmy_func(a,b) i=2 print(x) if__name__==’__main__’ x=10 my_func(1,2) print(i)

Переменная i определена только внутри функции, так что при запуске кода мы получаем ошибку NameError. Давайте немного модифицируем первый пример. Разместим данный код в python-файл и попытаемся его запустить:

Python

def my_func(a, b):
x = 5
print(x)

if __name__ == ‘__main__’:
x = 10
my_func(1, 2)
print(x)

1 2 3 4 5 6 7 8 9

defmy_func(a,b) x=5 print(x) if__name__==’__main__’ x=10 my_func(1,2) print(x)

1. Что, по-вашему, должно произойти?
2. Выдаст ли код цифру 10 дважды?

Нет, не выдаст. Причина в том, что мы имеем две переменные х. Переменная х внутри my_func имеет локальную область видимости функции и переопределяет переменную х вне функции. Так что когда мы вызываем функцию my_func, в выдаче мы видим 5, а не 10. Затем, когда функция возвращается, переменная х внутри функции my_func является кучей мусора и область для выдачи х срабатывает еще один раз. По этой причине последний оператор выдачи выдает именно 10. Если вы хотите кое-что поинтереснее, вы можете попытаться вывести х перед тем как назначить его в нашей функции:

Python

def my_func(a, b):
print(x)
x = 5
print(x)

if __name__ == ‘__main__’:
x = 10
my_func(1, 2)
print(x)

1 2 3 4 5 6 7 8 9 10

defmy_func(a,b) print(x) x=5 print(x) if__name__==’__main__’ x=10 my_func(1,2) print(x)

Кода вы запустите этот код, вы получите ошибку:

Python

UnboundLocalError: local variable ‘x’ referenced before assignment

1	UnboundLocalErrorlocal variable’x’referenced before assignment

Это происходит потому, что Python замечает, что вы назначаете х в функцию my_func позже, что и приводит к ошибке, так как х еще не определен.

Backwards compatibility

When type checkers add support for Literal, it’s important they do so
in a way that maximizes backwards-compatibility. Type checkers should
ensure that code that used to type check continues to do so after support
for Literal is added on a best-effort basis.

This is particularly important when performing type inference. For
example, given the statement x = "blue", should the inferred
type of x be str or Literal?

One naive strategy would be to always assume expressions are intended
to be Literal types. So, x would always have an inferred type of
Literal in the example above. This naive strategy is almost
certainly too disruptive — it would cause programs like the following
to start failing when they previously did not:

# If a type checker infers 'var' has type Literal
# and my_list has type List]...
var = 3
my_list = 

# ...this call would be a type-error.
my_list.append(4)

Another example of when this strategy would fail is when setting fields
in objects:

class MyObject:
    def __init__(self) -> None:
        # If a type checker infers MyObject.field has type Literal...
        self.field = 3

m = MyObject()

# ...this assignment would no longer type check
m.field = 4

An alternative strategy that does maintain compatibility in every case would
be to always assume expressions are not Literal types unless they are
explicitly annotated otherwise. A type checker using this strategy would
always infer that x is of type str in the first example above.

Defining a protocol

Protocols are defined by including a special new class typing.Protocol
(an instance of abc.ABCMeta) in the base classes list, typically
at the end of the list. Here is a simple example:

from typing import Protocol

class SupportsClose(Protocol):
    def close(self) -> None:
        ...

Now if one defines a class Resource with a close() method that has
a compatible signature, it would implicitly be a subtype of
SupportsClose, since the structural subtyping is used for
protocol types:

class Resource:
    ...
    def close(self) -> None:
        self.file.close()
        self.lock.release()

Apart from few restrictions explicitly mentioned below, protocol types can
be used in every context where a normal types can:

def close_all(things: Iterable) -> None:
    for t in things:
        t.close()

f = open('foo.txt')
r = Resource()
close_all()  # OK!
close_all()     # Error: 'int' has no 'close' method

Объектные переменные

Объектные переменные имеют индивидуальное значение внутри того или иного объекта.

В отличие от переменных класса, объектные переменные определяются внутри метода.

К примеру, в классе Shark переменные name и age являются объектными.

Объектные переменные определяются при создании класса Shark, а затем передаются объекту в качестве параметров метода конструктора или другого метода.

Как и переменные класса, объектные переменные можно отобразить:

Запустите программу:

Полученный результат состоит из значений переменных, которые были инициализированы для объекта new_shark.

Создайте ещё один объект класса Shark (например, stevie):

Объект stevie, как и объект new_shark, передает индивидуальные параметры экземпляра класса Shark.

Объектные переменные имеют разные значения внутри каждого объекта.

Inheritance

It is possible for a TypedDict type to inherit from one or more
TypedDict types using the class-based syntax. In this case the
TypedDict base class should not be included. Example:

class BookBasedMovie(Movie):
    based_on: str

Now BookBasedMovie has keys name, year, and based_on.
It is equivalent to this definition, since TypedDict types use
structural compatibility:

class BookBasedMovie(TypedDict):
    name: str
    year: int
    based_on: str

Here is an example of multiple inheritance:

class X(TypedDict):
    x: int

class Y(TypedDict):
    y: str

class XYZ(X, Y):
    z: bool

The TypedDict XYZ has three items: x (type int), y
(type str), and z (type bool).

A TypedDict cannot inherit from both a TypedDict type and a
non-TypedDict base class.

Additional notes on TypedDict class inheritance:

Основы работы с типами данных

Хорошим примером типов данных являются данные, которые используются в реальном мире: целые числа (0, 1, 2…), иррациональные числа (π), и т.п.

Как правило, в математических операциях можно комбинировать числа различных типов, например:

При этом можно оставить в качестве ответа полученное уравнение, а также можно округлить π до 3.14 и сложить числа:

Но если мы попытаемся решить уравнение, в котором кроме чисел будут присутствовать другие типы данных, например слова, мы не получим никакого вменяемого результата. К примеру, как бы вы решили следующее уравнение?

Компьютеры строго разграничивают все типы данных, потому нужно очень внимательно присваивать значения и использовать их в различных операциях.

@runtime_checkable decorator and narrowing types by isinstance()

The default semantics is that isinstance() and issubclass() fail
for protocol types. This is in the spirit of duck typing — protocols
basically would be used to model duck typing statically, not explicitly
at runtime.

However, it should be possible for protocol types to implement custom
instance and class checks when this makes sense, similar to how Iterable
and other ABCs in collections.abc and typing already do it,
but this is limited to non-generic and unsubscripted generic protocols
(Iterable is statically equivalent to Iterable).
The typing module will define a special @runtime_checkable class decorator
that provides the same semantics for class and instance checks as for
collections.abc classes, essentially making them «runtime protocols»:

from typing import runtime_checkable, Protocol

@runtime_checkable
class SupportsClose(Protocol):
    def close(self):
        ...

assert isinstance(open('some/file'), SupportsClose)

Note that instance checks are not 100% reliable statically, this is why
this behavior is opt-in, see section on ideas for examples.
The most type checkers can do is to treat isinstance(obj, Iterator)
roughly as a simpler way to write
hasattr(x, '__iter__') and hasattr(x, '__next__'). To minimize
the risks for this feature, the following rules are applied.

Definitions:

• Data, and non-data protocols: A protocol is called non-data protocol
  if it only contains methods as members (for example Sized,
  Iterator, etc). A protocol that contains at least one non-method member
  (like x: int) is called a data protocol.
• Unsafe overlap: A type X is called unsafely overlapping with
  a protocol P, if X is not a subtype of P, but it is a subtype
  of the type erased version of P where all members have type Any.
  In addition, if at least one element of a union unsafely overlaps with
  a protocol P, then the whole union is unsafely overlapping with P.

Specification:

Generics erasure

It would be easier to implement __class_getitem__ on the listed
standard collections in a way that doesn’t preserve the generic type,
in other words:

>>> list
<class 'list'>
>>> tuple
<class 'tuple'>
>>> collections.ChainMap]
<class 'collections.ChainMap'>

This is problematic as it breaks backwards compatibility: current
equivalents of those types in the typing module do preserve
the generic type:

>>> from typing import List, Tuple, ChainMap
>>> List
typing.List
>>> Tuple
typing.Tuple
>>> ChainMap]
typing.ChainMap]

As mentioned in the «Implementation» section, preserving the generic
type at runtime enables runtime introspection of the type which can be
used for API generation or runtime type checking. Such usage is already
present in the wild.

Additionally, implementing subscripts as identity functions would make
Python less friendly to beginners. Say, if a user is mistakenly passing
a list type instead of a list object to a function, and that function is
indexing the received object, the code would no longer raise an error.

Today:

>>> l = list
>>> l
TypeError: 'type' object is not subscriptable

With __class_getitem__ as an identity function:

>>> l = list
>>> l
list

Счетчики ссылок

Вся информация о типе хранится не в имени, а в объекте, на который ссылается переменная. Как только имя получает ссылку на новый объект, интерпретатор удаляет старый, освобождая память.

• >>>x = 12 # присваивает переменной x числовое значение.
• >>>x = «spam» # x становится строкой.
• >>>print(x).
• spam #12 полностью стирается и остается только строковый объект «spam».

В каждом объекте есть счетчик ссылок, за которым следит интерпретатор. Если их количество достигает нуля, объект безвозвратно удаляется, а место, которое он занимал, возвращается в пул свободной памяти. Такое поведение облегчает работу программиста и сокращает время на создание кода. Разработчику не нужно отдельно писать инструкции для уничтожения ненужных объектов.

По сравнению с Java или C++, синтаксис Python в разы проще. Благодаря динамической типизации, код занимает гораздо меньше места, с ним легко и приятно работать. Но, несмотря на видимую простоту и гибкость, Python – это язык со строгими правилами для каждого типа. Методы и операции применимые к одному виду объектов, недопустимы по отношению к другому:

• >>>f = «apple».
• >>>s = «cherry».
• >>>f * s # попытка умножить строки выведет сообщение об ошибке.

Non-goals

At runtime, protocol classes will be simple ABCs. There is no intent to
provide sophisticated runtime instance and class checks against protocol
classes. This would be difficult and error-prone and will contradict the logic
of PEP 484. As well, following PEP 484 and PEP 526 we state that protocols are
completely optional:

• No runtime semantics will be imposed for variables or parameters annotated
  with a protocol class.
• Any checks will be performed only by third-party type checkers and
  other tools.
• Programmers are free to not use them even if they use type annotations.
• There is no intent to make protocols non-optional in the future.

Interactions with Final

PEP 591 proposes adding a «Final» qualifier to the typing
ecosystem. This qualifier can be used to declare that some variable or
attribute cannot be reassigned:

foo: Final = 3
foo = 4           # Error: 'foo' is declared to be Final

Note that in the example above, we know that foo will always be equal to
exactly 3. A type checker can use this information to deduce that foo
is valid to use in any context that expects a Literal:

def expects_three(x: Literal) -> None: ...

expects_three(foo)  # Type checks, since 'foo' is Final and equal to 3

The Final qualifier serves as a shorthand for declaring that a variable
is effectively Literal.

If both this PEP and PEP 591 are accepted, type checkers are expected to
support this shortcut. Specifically, given a variable or attribute assignment
of the form var: Final = value where value is a valid parameter for
Literal, type checkers should understand that var may be used in
any context that expects a Literal.

Type checkers are not obligated to understand any other uses of Final. For
example, whether or not the following program type checks is left unspecified:

print

О функции print мы уже немного
говорили на предыдущем занятии, здесь рассмотрим подробнее различные
возможности ее использования. Например, эту функцию можно записывать в таких
вариациях:

print(1)
print(1, 2)
print(1, 2, 3)

И так далее,
число аргументов может быть произвольным. Соответственно все эти значения в
строчку будут выведены в консоли. Причем, значения разделяются между собой
пробелом. Это разделитель, который используется по умолчанию. Если нужно
изменить значение этого разделителя, то для этого используется специальный
именованный аргумент sep:

print(1, 2, 3, sep=",")
print(1, 2, 3, sep="-")
print(1, 2, 3, sep="***")

то есть, здесь можно прописывать самые разные строки-разделители.

Далее, вы уже
заметили, что каждый вызов функции print делает перевод
строки. Этот символ автоматически добавляет в конец выводимых данных. Но, мы
также можем его изменить. Для этого используется именованный аргумент end:

print(1, 2, 3, sep=",", end=':')
print(1, 2, 3, sep="-", end='--end--\n')
print(1, 2, 3, sep="***")

Смотрите, теперь
у нас после первой строчки нет перевода строки, а поставлено двоеточие с
пробелом, которые мы указали в аргументе end. После второго
вывода в конце была добавлена строчка и указан символ ‘\n’ перевода
строки.

В качестве
примера все это можно использовать для более гибкого вывода значений с помощью print:

name = "Федор"
print("Имя", name, sep=":")

Но это не самый
удобный вывод значений. Функция print позволяет делать довольно гибкий
форматированный вывод данных с применением спецификаторов. Например:

name = "Федор"; age = 18
print("Имя %s, возраст %d"%(name, age))

В результате,
вместо спецификатора %s будет подставлена первая переменная,
указанная в скобках, в виде строки, а вместо %d – вторая
переменная age в виде целого
числа. То есть, для каждого типа данных существует свой спецификатор. Наиболее
употребительные, следующие:

• %d, %i, %u – для вывода целочисленных
  значений;

• %f – для вывода
  вещественных значений;

• %s
  – для
  вывода строк;

• %%
  — для
  вывода символа %

Вот основные
возможности функций input и print в Python.

Видео по теме

Python 3 #1: установка и запуск интерпретатора языка

Python 3 #2: переменные, оператор присваивания, типы данных

Python 3 #3: функции input и print ввода/вывода

Python 3 #4: арифметические операторы: сложение, вычитание, умножение, деление, степень

Python 3 #5: условный оператор if, составные условия с and, or, not

Python 3 #6: операторы циклов while и for, операторы break и continue

Python 3 #7: строки — сравнения, срезы строк, базовые функции str, len, ord, in

Python 3 #8: методы строк — upper, split, join, find, strip, isalpha, isdigit и другие

Python 3 #9: списки list и функции len, min, max, sum, sorted

Python 3 #10: списки — срезы и методы: append, insert, pop, sort, index, count, reverse, clear

Python 3 #11: списки — инструмент list comprehensions, сортировка методом выбора

Python 3 #12: словарь, методы словарей: len, clear, get, setdefault, pop

Python 3 #13: кортежи (tuple) и операции с ними: len, del, count, index

Python 3 #14: функции (def) — объявление и вызов

Python 3 #15: делаем «Сапер», проектирование программ «сверху-вниз»

Python 3 #16: рекурсивные и лямбда-функции, функции с произвольным числом аргументов

Python 3 #17: алгоритм Евклида, принцип тестирования программ

Python 3 #18: области видимости переменных — global, nonlocal

Python 3 #19: множества (set) и операции над ними: вычитание, пересечение, объединение, сравнение

Python 3 #20: итераторы, выражения-генераторы, функции-генераторы, оператор yield

Python 3 #21: функции map, filter, zip

Python 3 #22: сортировка sort() и sorted(), сортировка по ключам

Python 3 #23: обработка исключений: try, except, finally, else

Python 3 #24: файлы — чтение и запись: open, read, write, seek, readline, dump, load, pickle

Python 3 #25: форматирование строк: метод format и F-строки

Python 3 #26: создание и импорт модулей — import, from, as, dir, reload

Python 3 #27: пакеты (package) — создание, импорт, установка (менеджер pip)

Python 3 #28: декораторы функций и замыкания

Python 3 #29: установка и порядок работы в PyCharm