Как проверяется текущая версия Python?
Допустим, вам нужно выбрать конкретное действие в зависимости от версии используемого интерпретатора.
В моём примере мне нужна версия Python больше чем 3.5.
Самый очевидный способ проверки мажорной версии такой:

>>> import sys
>>> print sys.version_info.major > 3
True

С минорной версией будет чуть длинней

>>> print sys.version_info.major == 3 and sys.version_info.minor > 5

Можно ли сократить эту запись?
Конечно! Иначе поста бы не было 😊

Вспоминаем как работает сравнение итерируемых объектов в Python. Элементы сравниваются попарно. Если первая пара совпала, проверяется следующая пара, и так пока не найдутся разные элементы или закончится один из итераторов. Например, сравним кортежи.

>>> (1, 2) > (1, 3)
False
>>> (1, 4, 5) > (1, 4, 3)
True

Теперь преобразуем version_info в кортеж (или список)

>>> tuple(sys.version_info)
(3, 7, 3, 'final', 0)

И можем использовать его для сравнения кортежей

>>> tuple(sys.version_info) > (3, 5)
True

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

>>> sys.version_info > (3, 5)
True

Можно еще как-то иначе? Можно!
Строки тоже итерируемый объект. Они сравниваются не по длине или кодам символов, а так же попарно, и по порядку символа в таблице (или в алфавите).

>>> 'a' > 'b'
False
>>> 'e' > 'c'
True
>>> '5' < '4'
False

А что у нас есть еще в sys? Правильно, переменная version.

>>> print (sys.version)
'3.7.3 (default, Dec 20 2019, 18:57:59) \n[GCC 8.3.0]'

Сравниваем эту переменную с другой строкой:

>>> sys.version > '3.5'
True

⚠️ Этот метод со строкой перестанет работать когда версия Python станет 3.10+. Не используйте его!

# tricks

В стандартной библиотеке Python есть поддержка нескольких текстовых форматов файлов.
Я имею в виду общепринятые форматы хранения текстовых данных. Чаще всего это конфигурационные файлы.
И вот что может читать Python из коробки:

🔸 JSON (JavaScript Object Notation)

Модуль json

Один из лидеров по популярности. Используется во многих сферах, от простых конфигов до протоколов передачи данных.
Формат простой и понятный. Очень похож на простой Python-код.
https://ru.wikipedia.org/wiki/JSON
https://www.json.org/

🔸 CSV (Comma-Separated Values)

Модуль csv

Формат описания табличных данных. Его используют аналитики, датасаентисты и Exel-мастера. Что-то вроде текстовой базы данных.
https://ru.wikipedia.org/wiki/CSV
https://www.w3.org/TR/tabular-data-primer/

🔸 XML (eXtensible Markup Language)

Модуль xml

Самый популярный формат в WEB, так как любая HTML страница (то есть все страницы в сети) это XML. Многие программы используют эту разметку для сохранения данных. Удобный формат многоуровневой вложенности объектов с атрибутами.
https://www.xml.com/
https://ru.wikipedia.org/wiki/XML

🔸 INI (Initialization file)

Модуль configparser

Очень простой формат конфига для Windows с возможностью группировать параметры.
Мало популярен, но в простых случаях вполне подходит.
https://ru.wikipedia.org/wiki/.ini


Есть еще один популярный формат для конфигов, но к сожалению не в стандартной поставке. Я решил его тоже упомянуть.

🔹 YAML (Yet Another Markup Language)

В основном используется для конфигов.
https://ru.wikipedia.org/wiki/YAML
https://yaml.org/

Установка:

pip install pyyaml

___________
Конечно же существуют и другие форматы. CFG или CONF (парсер для него был в стандартной библиотеки Python2 в модуле ConfigParser), TOML и другие. Но в большинстве случаев стандартно поддерживаемых форматов хватает чтобы закрыть все потребности.

#libs

Почему форматов для хранения простых конфигов так много? Всё как обычно. В какой-то момент возникает ситуация:

АДМИН: Этот конфиг просто не поддерживает то что я от него хочу!
ПРОГЕР: Подержите моё пиво...

И рождается новый формат)))

А если серьёзно, разные форматы поддерживают разный функционал. Например, поддержка группировки, вложенности данных, глубина вложенности, поддержка разных структур данных, поддержка экспрешенов и наследования, удобство расширения и тд.

Возможно самое главное, это человекочитаемость!
Так как очень часто конфиги пишут и читают люди. Если бы это было не так, то все писали бы в binary и не выдумывали всякое хитрое форматирование.

На мой взгляд самый удобный в коде это JSON, а самый читаемый и удобный в ручном редактировании это YAML.

Никто не мешает вам создать собственный формат, если не достаточно того что имеется или если слишком много свободного времени)

PS. 4 формата рядом для сравнения синтаксиса 🌎

#libs

Что за магический модуль ˍˍfutureˍˍ?

Это имплементация поведения интерпретатора из будущих версий Python.

Разные версии в Python развиваются параллельно. Разработчики ядра Python внедрили модуль ˍˍfutureˍˍ чтобы помочь писать код на старых версиях, но совместимый с новыми версиями интерпретатора. Это помогает более мягко обновить Python, не переписывая всю кодовую базу. Можно сказать что это бекпорт фичей.

Модуль ˍˍfutureˍˍ позволяет "импортировать" функционал Python3 работая с Python2, или использовать фишки из Python3.9 имея в распоряжении только 3.6.

Но что именно делает этот модуль? Если вы откроете исходник, то ничего магического вы там не найдете. Простой класс, несколько флагов и набор инстансов этого класса. По идее, если его импортнуть, ничего поменяться не может, так как там нет никакого исполняемого кода! Только объявления объектов.

А ответ кроется в необходимости делать импорты из ˍˍfutureˍˍ самой первой строкой. Дело в том, что парсер специально заточен на поиск импорта этого модуля в первой строке. Он смотрит что вы там импортнули и специальным образом изменяет поведение интерпретатора, которое в него вшито с помощью бекпортов. Весь дальнейший синтаксический разбор будет с учётом изменений. Именно поэтому импорт ˍˍfutureˍˍ обязательно должен быть первым! Не можем же мы половину модуля исполнять по-старым правилам а вторую половину по-новым)))

#2to3

Что именно мы можем импортнуть из будущих версий? Явно не всё, иначе это была бы, собственно, новая версия. В ˍˍfutureˍˍ выносятся только ключевой функционал, от которого серьезно зависит синтаксис или использование возможностей языка. Самое очевидное это директива print, которая в Python3 стала функцией print().

from __future__ import print_function

Что стало удобней с этой функцией?

🔸 Теперь это функция а не ключевое слово, её можно передать как аргумент или вернуть как результат

def get_logger():
if condition:
return some_handler.write
else:
return print

🔸 С помощью аргументов sep и end можем настроить минимальное форматирование вывода.

sep: разделитель для нескольких объектов
end: последний символ вместо перехода на новую строку

>>> items1 = [1, 2, 3]
>>> items2 = [4, 5, 6]
>>> print(*items1, sep='-', end='-')
>>> print(*items2, sep='-')
1-2-3-4-5-6

🔸 Аргумент flush форсированно пробрасывает буфер аутпута в файл. Полезно для вывода из блокирующих операций. Например, когда вам нужно в stdout выводить прогресс операции, запущенной в subprocess. Если не сделать flush то весь аутпут прилетит только по завершению процесса.

for i in range(100):
print(f'Progress: {i}%', flush=True)
time.sleep(1)

Этот прогресс мы можем отслеживать в реальном времени.
А вот так приходилось делать раньше:

import sys
sys.stdout.write(text + '\n')
sys.stdout.flush()

🔸 Аргумент file позволяет перенаправить вывод в другой поток. Например в файл, сеть или что угодно, что имеет метод write.

print(text, file=open('filename.txt', 'w'))
___________
Ну да, теперь приходится писать лишние скобочки и сложно переучиться на новый лад. Но плюсов, я думаю, больше.

#2to3 #tricks

Вторая по частоте future-функция, которую я использовал, это абсолютный импорт

from __future__ import absolute_import

Что она делает?
Изменения, которые вносит эта инъекция описаны в PEP328
Покажу простой пример.

Допустим, есть такой пакет:

/my_package
/__init__.py
/main.py
/string.py

Смотрим код в my_package/main.py

# main.py
import string

Простой пример готов) Вопрос в том, какой модуль импортируется в данном случае? Есть два варианта:

1. модуль в моём пакете my_package.string
2. стандартный модуль string

И вот тут вступает в дело приоритет импортов. В Python2 порядок следующий: помимо иных источников, раньше ищется модуль внутри текущего пакета, а потом в стандартных библиотеках. Таким образом мы импортнём my_package.string.

Но в Python3 это поведение изменилось. Если мы указываем просто имя пакета, то ищется именно такой модуль, игнорируя имена в текущем пакете. Если мы хотим импортнуть именно подмодуль из нашего пакета то, мы должны теперь явно это указывать.

from my_package import string

или относительный импорт, но с указанием пути относительно текущего модуля main

from . import string

Еще одной неоднозначностью меньше 😎

Подробней про импорты здесь:
https://docs.python.org/3/tutorial/modules.html

#2to3 #pep #basic

Ранее я уже упоминал о другой фишке из ˍˍfutureˍˍ , это оператор деления.

from __future__ import division

Суть проста. Раньше сложность типа данных результата поределялась типом самого сложного операнда.
Например:

int/int => int
int/float => float

В первом случае оба операнда int, значит и результат будет int. Во втором float более сложный тип, поэтому результат будет float.

Если нам требуется получить дробное значение при делении двух int то приходилось форсированно один из операндов конверировать в float.

12/float(5) => float

Но с новой "философией" это не требуется. В Python3 "floor division" заменили на "true division" а старый способ теперь работает через оператор "//".

>>> 3/2
1.5
>>> 3//2
1

То есть теперь деление int на int даёт float если результат не целое число.
В классах теперь доступны методы __floordiv__() и __truediv__() для определения поведения с этими операторами.

Данный переход описан в PEP238.

#pep #2to3 #basic

Когда разрабатываете свой GUI с помощью PyQt для какого-либо софта бывает необходимо позаимствовать цвета из текущего стиля интерфейса. Например, чтобы правильно раскрасить свои виджеты, подогнав их по цвету. Ведь бывает, что ваш GUI используется в разных софтах. Причём некоторые со светлой темой а другие с тёмной.
По умолчанию стили наследуются, но если вы задаёте какую-либо раскраску для части виджета через свой styleSheet, то требуется ссылаться на цвета текущего стиля.

Как это сделать? Как получить нужный цвет из палитры имеющегося стиля? Это достаточно просто, нужно использовать класс QPalette и его роли.

Например, мне нужно достать цвет текста из одного виджета и применить его в другом как цвет фона (не важно зачем именно так, просто захотелось😊).

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

from PySide2.QtGui import QPalette
color = main_window.palette().color(QPalette.Text)

теперь можем использовать этот цвет в стилях

my_widget.setStyleSheet(f'background-color: {color.name()};')

Готово, мы динамически переопределили дефолтный стиль используя текущий стиль окна!

На самом деле есть запись покороче, в одну строку и без лишних переменных. Не очень-то по правилам CSS, но Qt это понимает.

my_widget.setStyleSheet('background-color: palette(Text);')

Этот способ не подходит если вам нужно как-то модифицировать цвет перед применением в своих стилях. В этом случае потребуется первый способ.
Зато он прекрасно сработает в файле .qss, то есть не придётся в коде прописывать раскраску отдельных элементов через ссылки на палитру, всё красиво сохранится в отдельном файле .qss!

QListView#my_widget::item:selected {
     background: palette(Midlight);
}

Про имеющиеся роли можно почитать здесь 🌍

#qt #tricks

Думаете ˍˍfutureˍˍ нужен только для Python2? Нет, это процесс постоянный. В Python3 тоже есть свои "future".

from __future__ import annotations

Похоже на бекпорт аннотаций типов из Python3 в Python2, но это не так. Это имплементация PEP 563 Postponed Evaluation of Annotations которая будет дефолтной только в Python4.

Что делает этот future?
Если вы активно используете аннотации типов в Python3 то знаете, как они обычно выглядят.

def func(x: int) -> int:
return x * 2

При этом у объекта функции появляется атрибут ˍˍannotationsˍˍ

>>> print(func.__annotations__)
{'x': <class 'int'>, 'return': <class 'int'>}

Видно, что в этой переменной находится словарь. Ключ словаря это имя аргумента функции, а значение это непосредственно ссылка на тип. А так же есть тип для return.

В более сложных случаях это будут инстансы объектов из модуля typing

from typing import List

def func(x: int) -> List[int]:
return [x] * 10

>>> print(func.__annotations__)
{'x': <class 'int'>, 'return': typing.List[int]}

Что происходит если мы импортим annotations из ˍˍfutureˍˍ? Изменяется способ определения аннотаций.

Дело в том, что все эти инстансы типов создаются в момент определения функции когда модуль импортируется. Так же как и значения по умолчанию они должны исполниться и вернуть какой-то объект. В нашем случае это ссылка на тип int или инстанс класса typing.List.
И тут возникает две проблемы, описаные в PEP.
Если коротко то звучит это так:

1. Если в подсказке указывается тип, который еще не определён, это вызовет ошибку. Приходится описывать его просто строкой или менять порядок определения.

2. Определение ссылок на типы порой занимает много времени, так как требуется импорт модулей и создание инстансов.

Но если вы импортируете наш future, то активируется так называемое отложенное определение ссылок (Postponed Evaluation of Annotations).

В результате вместо создания инстансов и ссылок в ˍˍannotationsˍˍ просто записывается строка с этой подсказкой.

from __future__ import annotations

def func(x: int) -> int:
return x * 2

>>> print(func.__annotations__)
{'x': 'int', 'return': 'int'}

В дальнейшем ваши IDE и ресолверы типов могут брать эти строки и исполнять самостоятельно где то на фоне, когда все необходимые типы уже определены.
Для преобразования этих строк в привычный вид есть готовая функция

>>> import typing
>>> typing.get_type_hints(func)
{'x': <class 'int'>, 'return': <class 'int'>}

Но делать это можно уже только по необходимости.

#pep

Небольшой трик с регулярными выражениями который редко вижу в чужом коде.

Допустим, вам нужно распарсить простой текст и вытащить оттуда пары имя+телефон. Вернуть всё это надо в виде списка словарей. Возьмем очень простой пример текста.

>>> text = '''
>>> Alex:8999123456
>>> Mike:+799987654
>>> Oleg:+344456789
>>> '''

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

(\w+):([\d+]+)

Как мы будем формировать словарь из найденных групп?

>>> import re
>>> results = []
>>> for match in re.finditer(r"(\w+):([\d+]+)", text):
>>> results.append({
>>> "name": match.group(1),
>>> "phone": match.group(2)
>>> })
>>> print(results)
[{'name': 'Alex', 'phone': '8999123456'}, ...]

Можно немного сократить запись используя zip

>>> results = []
>>> for match in re.finditer(r"(\w+):([\d+]+)", text):
>>> results.append(dict(zip(['name', 'phone'], match.groups())))

Но есть способ лучше! Это именованные группы в regex. Можно в паттерне указать имя группы и результат сразу забрать в виде словаря.

>>> for match in re.finditer(r"(?P<name>\w+):(?P<phone>[\d+]+)", text):
>>> results.append(match.groupdict())

То есть всё что я сделал, это добавил в начале группы (внутри сбокочек) такую запись:

(?P<group-name>...)

Теперь найденная группа имеет имя и можно обратиться к ней как к элементу списка

>>> name = match['name']

Либо забрать сразу весь словарь методом groupdict()

>>> match.groupdict()

#tricks #regex

Как разделить один список на два по определённому признаку элементов? Самый очевидный способ выглядит так:

array = [1, 2, 3, 4, 5, 6, 7, 8, 9]
even, odd = [], []

for item in array:
    if item%2:
        odd.append(item)
    else:
        even.append(item)

Смотрим что получается

>>> odd
[1, 3, 5, 7, 9]
>>> even
[2, 4, 6, 8]

А теперь способ в одну строку!
(ну кто бы сомневался 😂)

_ = [[even.append, odd.append][x%2](x) for x in array]

Я специально сохранил результат в переменную "_", так как этот результат нам не нужен. Вся магия происходит во время выполнения генератора списка.
Выражение x%2 возвращает нам 1 или 0, что является индексом списка [even.append, odd.append]. Таким образом происходит выбор метода append() для нужного списка и сразу после этого мы вызываем его, отправляя очередной элемент в выбранный список.

Точно так же в выражение можно ставить сравнение, которое вернёт bool. Ведь вы помните, что bool это производный тип от int, а значит True это 1 а False это 0.

>>> arr = [100, 200]
>>> print(arr[True])
200
>>> print(arr[False])
100

В нашем случае можно сделать так

more, less = [], []
[[less.append, more.append][x>5](x) for x in array]

Можно даже никуда не сохранять результат, всё равно то что нам нужно произойдет.

>>> print(more, less)
[6, 7, 8, 9], [1, 2, 3, 4, 5]

#tricks

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

array = [1, 2, 3, 4, 5, 6, 7, 8, 9]
more, less = [], []
map(lambda x: [less.append, more.append][x>5](x), array)

Проверяем результат

>>> print(more, less)
[] []

Хм, не сработало! Что произошло? Почему итерация не запустилась?
Дело в том, что в Python3 многие итеративные функции (если не все) стали генераторами. А что такое генератор? Это не тот генератор списка который List Comprehensions, а именно Generator.
Объект, который внутри себя имеет алгоритм получения следующего элемента и он не станет запускать итерацию пока мы не начнём запрашивать эти элементы.

Что возвращает функция map()?

>>> print(map(...))
<map object at 0x0000023114ADE3C8>

Тоже самое произошло и с функцией range

>>> print(range(10))
range(0, 10)

Значит всё что остаётся, это запустить итерацию по элементам генератора. Как это сделать максимально коротко?
Можно просто в цикле for

for _ in map(...): pass

Либо конвертнуть в список

list(map(...))

Или оператором *

[*map(...)]

Ну а полностью будет выглядеть так

[*map(lambda x: [less.append, more.append][x>5](x), array)]

Теперь генератор сразу вычисляется. Хотя, как по мне, такая запись менее "читабельна")

#tricks

В моих триках вы часто можете видеть способы сокращения кода. Когда длинный код заменяется на однострочный. Скорее всего, я продолжу эту практику, но хочу напомнить о важной вещи!

⚠️ Понятное лучше чем запутанное ⚠️

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

Если это можно сделать в Python, то это не значит что это нужно сделать.

Смотрим реальный пример из моей практики, когда я увлёкся и загнал все сравнения в один оператор if

>>> if any([fnmatch(rel, pat) for pat in include_files]) and not any([fnmatch(rel, pat) for pat in ignore_files]) and not any([any([fnmatch(name, pat) for pat in ignore_files]) for name in Path(rel).parts]):
>>> do_comething()

Да, это всего две строки))) Страшная мешанина!

Почему это плохо?
🔸 Это круто когда "заработало" но не круто когда через время смотришь на код и не поймешь что он делает.
🔸 Когда через время попробуешь что-то поправить, становится проще переписать заново (мой случай 😉)
🔸 Если работаете в команде, можно получить знатных [подставить страшное слово]лей. Такой код просто невозможно поддерживать.
Можно получить знатной брани на свою голову от себя же, пока не вспомнишь что это ты и писал)
🔸Если вы решились немного сгладить вину и расставить комментарии, то в однострочном выражении это не всегда получится. Символ игнора перехода на новую строку не позволит вам за ним писать комментарий.
Оба выражения ниже вызовут ошибку синтаксиса

x = 1 + \   # comment
    2

x = 1 + \
    # comment
    2

Делайте код проще, избегайте сокращений, которые снижают читабельность кода.

⚠️ Простое лучше сложного ⚠️

А тем, кто еще не понял: import this

Помните пример с неудачной вставкой комментария?

x = 1 + \ # comment
2

x = 1 + \
# comment
2

Я говорил что так делать не стоит, так как вызывает ошибку. Но я же скажу как эту ошибку поправить! И это просто (((СКОБОЧКИ))) 😎!

x = (1 + # comment
2)

x = (1 +
# comment
2)

Теперь интерпретатор сообразит что к чему.
Кстати, они же помогают избежать символа "\" в других случаях

Без скобок

from Qt.QtWidgets import QPushButton, QLabel, \
QTextEdit, QListWidget

Со скобками

from Qt.QtWidgets import (QPushButton, QLabel,
# здесь можно вставить комментарий
QTextEdit, QListWidget)

Без скобок

if a > 0 \
and b > 0 \
and c < 10:
pass

Со скобками

if (a > 0
# комент
and b > 0
# комент
and c < 10):
pass

Но прошу заметить, как порой страшно выглядят данные конструкции. Применяйте осторожно!
Да и лишние скобки в Python смотрятся не всегда уместно)

#tricks

Стандартный модуль json имеет command line интерфейс. Он умеет делать валидацию JSON-данных и переводить однострочный вариант в форматированный.

Изменяем форматирование

$ echo '{"key1": "value1", "key2": "value2"}' | python3 -m json.tool
{
"key1": "value1",
"key2": "value2"
}

Заменяем прямой ввод данных на данные из файлов

python3 -m json.tool < single.json > pretty.json

Вместо stdin и stdout просто передаём путь к файлам, результат тот же.

python3 -m json.tool single.json pretty.json

Как происходит валидация? Да просто команда завершится с ошибкой если формат данных неверный (exit code 1). В stderr распечатается информация о том где произошёл сбой.

#libs

Регулярные выражения иногда могут быть просто монструозными. Выглядеть это может крайне запутанно. Сами регэкспы и без того история непростая, а когда это длинный паттерн на несколько десятков знаков, разобрать там что-либо становится не просто.

Но на помощь приходит Python и его стремление сделать нашу жизнь проще!

В функциях регулярок можно после паттерна указывать флаги, один из которых позволяет писать паттерны более свободно. А именно, добавлять пробелы и переносы, которые будут игнорированы. В результате мы можем разбить паттерн на строки и добавить комментов.

Чтобы это сработало нужно добавить флаг re.VERBOSE. Пробелы в паттерне теперь следует указывать явно спец символами.
Согласитесь, что даже с именованными группами а таком виде регэкспа выглядит вполне сносно 😉.

#tricks #regex

20 апреля 2020 года вышел последний релиз Python версии 2. Им стал билд 2.7.18. На этом точно всё, официально версия закрыта.
Развитие будет только за счёт сторонних разработчиков в контексте их проектов, где 2й Python никак не обойти.

Хотите оформить свои CLI скрипты красивым прогрессбаром?
Стоит посмотреть на библиотеку progress.
Она даёт возможность создавать красивые прогрессбары легко и быстро.

Но что если не хочется добавлять лишнюю зависимость только ради одной бегущей полоски?
Создать свою функцию с подобным функционалом — не проблема!

Вот базовый набросок:

import time
for i in range(0, 100+1, 4):
time.sleep(0.1)
print('\r{:>3}% [{}{}]'.format(i, "#"*i, '-'*(100-i)), end='')
print()

Запустите код в интерактиве и увидите что работает не хуже.
Вся хитрость в отсутствии переноса на новую строку в конце строки и в символе "\r" — возврат "каретки" (читай "курсора") в начало строки. После чего мы перезаписываем предыдущую строку.
Главное в самом конце не забыть обычный print() чтобы перейти на новую строку.

Расширенный вариант в виде контекст менеджера. 🌎

#libs #tricks

Ранее я делал серию постов про битовые операторы.
Вот вам ещё один наглядный пример как это используется в Python в модуле re.

Чтобы указать флаг для компилятора нам надо указать его после передаваемой строки. Например, добавляем флаг для игнорирования переноса строки.

pattern = re.compile(r"(\w+)+")
words = pattern.search(text, re.DOTALL)

А как указать несколько флагов? Ведь явно будут ситуации когда нам потребуется больше одного. Кто читал посты по битовые операторы уже понял как.

pattern.search(text, re.DOTALL | re.VERBOSE)

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

>>> for n in [1, 2, 4, 8, 16, 32, 64, 128, 256]:
>>>
print(bin(n))

0b1
0b10
0b100
0b1000
0b10000
0b100000
0b1000000
0b10000000
0b100000000

Чтобы было понятней, давайте напишем тоже самое но иначе, добавим ведущие нули:

000000001
000000010
000000100
000001000
000010000
000100000
001000000
010000000
100000000

Не понятно что тут происходит? Читай три поста про битовые операторы начиная с этого ➡️ https://t.iss.one/pythonotes/45

В общем, это пример применения побитовых операций в самом Python.
Теперь вы знаете Python еще немного лучше)

#tricks #regex #libs

Каждый модуль в Python имеет атрибут ˍˍnameˍˍ. В него записывается строка, содержащая полное имя модуля. Например:

>>> from my_package import my_module
>>> print(my_module.__name__)
'my_package.my_module'

Очень удобно для логгинга когда в имя логгера требуется записать имя модуля, в котором происходят события лога.
Но однажды мне потребовалось создать логгер не для модуля в целом, а для отдельной функции. Что в этом случае можно сделать?
Такой объект как функция тоже имеет атрибут ˍˍnameˍˍ

>>> class MyClass:
>>> def func(self):
>>> pass
>>> print(MyClass.func.__name__)
'func'

Итого нам следует собрать полное имя таким образом:

>>> full_name = '.'.join([__name__, MyClass.__name__, MyClass.func.__name__])
>>> print(full_name)
'my_package.my_module.MyClass.func'

А что если класс вложен в другой класс?

>>> class MyClass:
>>> class SubClass:
>>> def func(self):
>>> pass
>>> full_name = '.'.join([__name__, MyClass.__name__, MyClass.SubClass.__name__, MyClass.SubClass.func.__name__])
>>> print(full_name)
'my_package.my_module.MyClass.SubClass.func'

А что если вложений несколько?

>>> class MyClass:
>>> class SubClass1:
>>> class SubClass2:
>>> def func(self):
>>> pass

Даже не буду писать пример получения имени 😭.
А что если функция не из этого класса а унаследована и вы работаете с внешней библиотекой?

>>> from somewhere.something import OtherClass

>>> class MyClass2(OtherClass):
>>> pass

Cтрашно подумать как нам достать настоящее "полное имя" функции! А если там динамическое определение наследования или метаклассы? Вообще можно забить на решение и придумать другой способ 😵

На помощь приходит PEP3155 и его имплементация "Qualified name".

Всё очень просто, начиная с Python 3.3 классы и функции имеют атрибут ˍˍqualnameˍˍ, который и содержит полное или "честное" или "квалифицированное" имя объекта. Именно в него уже записан готовый полный адрес объекта. И теперь даже такая конструкция сработает правильно:

>>> # some_module.py
>>>
>>> class OtherClass:
>>> class SubClass1:
>>> class SubClass2:
>>> def func(self):
>>> pass
>>>
>>> # my_module.py
>>> from some_module import OtherClass
>>> class FinalClass(OtherClass.SubClass1.SubClass2):
>>> pass
>>>
>>> full_name = '.'.join([__name__, FinalClass.func.__qualname__])
'my_package.my_module.OtherClass.SubClass1.SubClass2.func'

Тут стоит заметить, что если функция находится не в текущем модуле а откуда-то импортирована (как в моём примере) то собирать имя с локальным атрибутом ˍˍnameˍˍ уже не имеет особого смысла. Тогда лучше использовать имя модуля исходного класса:

>>> full_name = '.'.join([FinalClass.__module__, FinalClass.func.__qualname__])
'some_module.OtherClass.SubClass1.SubClass2.func'

#pep