Знаете ли вы про "магические" методы классов ˍˍgetattributeˍˍ() и ˍˍgetattrˍˍ()?

ˍˍgetattributeˍˍ вызывается всякий раз когда идёт обращение к атрибуту объекта. Например метод или какая-то переменная.

ˍˍgetattrˍˍ вызывается когда атрибут не найден.

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

Но пост на самом деле не об этом. Дело в том, что в Python 3.7 добавили возможность определять функцию ˍˍgetattrˍˍ() в модуле с аналогичной функциональностью! (PEP562)

То есть, создав внутри модуля функцию ˍˍgetattrˍˍ() мы определяем действие в случае запроса несуществующего атрибута модуля. Ровно так же как это делаем в классах. Тем самым можно динамически определять состав модуля.

А еще можно создать функцию ˍˍdirˍˍ(), определяющую поведение для стандартной функции dir().

Пример модуля:

# example.py

my_variables = {'var1': 1, "var2": 2}

def __getattr__(name):
    try:
        return my_variables[name]
    except KeyError:
        raise AttributeError

def __dir__():
    return list(my_variables.keys())

Как использовать модуль

>>> import example
>>> print(example.var1)
1
>>> print(example.var3)
AttributeError

>>> print(dir(example)))
['var1', 'var2']

#tricks #pep

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

Например, в обычном (не интерактивном) режиме команда input() приведет к ошибке (ожидание ввода с клавиатуры). А в интерактивном режиме не всегда получится открыть какой-то диалог. Этот экспрешн поможет выбрать способ ввода данных, например авторизация пользователя.

is_interactive = bool(getattr(sys, 'ps1', sys.flags.interactive))

Возможно, кто-то скажет: "зачем такие сложности??? Просто проверяем наличие переменной ˍˍfileˍˍ, в интерактивном режиме она не создаётся!"

Всё верно, так оно и работает, но только до того момента, пока вы не импортируете какой-либо модуль. Внутри неймспейса этого модуля переменная ˍˍfileˍˍ определённо существует, даже если вы импортнули его в интерактиве. То есть внутри модуля способ не работает. А с помощью нашего выражения проверка правильно сработает в любом случае.

PS. Не работает с некоторыми режимами эмуляции интерпретатора.

#tricks

Как проверяется текущая версия 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