Сидите вы на работе и смотрите на дневную статистику по заявкам разных типов:

monday = {"question": 1, "problem": 3, "idea": 2}
tuesday = {"problem": 5, "idea": 1}
wednesday = {"question": 2, "problem": 2}

Задача — посчитать агрегированную статистику за все дни. Всё вроде понятно. Тут подходит тимлид и говорит, что если решите задачу однострочником, он подарит вам жёлтую резиновую уточку.

Устоять перед этим решительно невозможно.

Словари → счётчики

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

>>> mapped = map(abs, [-1, -2, -3])
>>> list(mapped)
[1, 2, 3]

abs() возвращает абсолютное значение числа, а list() тут нужен, чтобы отработал map (сам по себе он ленивый, пока не пнёшь — не полетит).

В нашем случае последовательностью будет набор дневных статистик, а функцией — конструктор счётчика:

>>> map(Counter, [monday, tuesday, wednesday])
<map object at 0x10cae2470>

map object — это итератор, который сделает из словарей счётчики, когда нам это действительно понадобится — в момент суммирования.

Счётчики → агрегат

Окей, теперь осталось только посчитать сумму от этого добра. Как мы знаем, у счётчиков перекрыт оператор сложения, так что почему бы просто не вызвать sum() на них?

>>> sum(map(Counter, [monday, tuesday, wednesday]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'Counter'

Эээ, что? Откуда тут int, мы же суммируем объекты Counter?

Оказывается, функция sum() принимает два аргумента:

1. последовательность, которую суммируем
2. первое слагаемое для итоговой суммы, по умолчанию — 0

Например:

>>> sum([1, 2, 3])
6

>>> sum([1, 2, 3], 10)
16

Получается, в нашем случае sum() пытается сложить 0 со счётчиком от monday, и, естественно, ломается. Решение — передать в качестве первого слагаемого пустой счётчик:

sum(..., Counter())

Объединяем всё вместе:

>>> sum(map(Counter, [monday, tuesday, wednesday]), Counter())
Counter({'problem': 10, 'question': 3, 'idea': 3})

Готово!

Почему вздыхает Гвидо

Гвидо ван Россум недолюбливает map() и, кажется, функциональщину как таковую. Вместо неё он предпочитает пользоваться comprehensions.

В нашем случае вместо map() можно использовать такую конструкцию:

(Counter(stat) for stat in [monday, tuesday, wednesday])

Используйте с осторожностью

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

daily_stats = map(Counter, [monday, tuesday, wednesday])
empty_stat = Counter()
sum(daily_stats, empty_stat)

А если не хотите, чтобы читатель мучительно вспоминал, что за такой второй аргумент в sum(), можно и вовсе сделать так:

daily_stats = map(Counter, [monday, tuesday, wednesday])
functools.reduce(operator.add, daily_stats)

Лично мне такой вариант даже больше нравится ツ

Вернёмся к примеру со статистикой по заявкам разных типов. Вот данные о вопросах, проблемах и идеях за три дня:

monday = {"question": 1, "problem": 3, "idea": 2}
tuesday = {"problem": 5, "idea": 1}
wednesday = {"question": 2, "problem": 2}

Как бы посчитать агрегированную статистику? Можно так, конечно:

def add_day(day_stats, stats):
  for key, value in day_stats.items():
    stats[key] += value
  return stats

stats = {"question": 0, "problem": 0, "idea": 0}
stats = add_day(monday, stats)
stats = add_day(tuesday, stats)
stats = add_day(wednesday, stats)

stats
{'question': 3, 'problem': 10, 'idea': 3}

Но вы наверняка догадываетесь, что это не наш метод. Поможет арифметика со счётчиками:

from collections import Counter

monday = Counter({"question": 1, "problem": 3, "idea": 2})
tuesday = Counter({"problem": 5, "idea": 1})
wednesday = Counter({"question": 2, "problem": 2})

stats = monday + tuesday + wednesday

stats
Counter({'problem': 10, 'question': 3, 'idea': 3})

Что насчёт самого популярного типа заявок?

stats.most_common(1)
[('problem', 10)]

А какие типы заявок встречались во вторник и в среду?

(tuesday | wednesday).keys()
dict_keys(['problem', 'idea', 'question'])

А сколько проблем было за все дни кроме понедельника?

(stats - monday)["problem"]
7

Думаю, вы уловили идею ツ

P.S. Хотите реально злую штуку? Вот как посчитать агрегированную статистику в одну строчку:

sum(map(Counter, [monday, tuesday, wednesday]), Counter())

Послушал очередной выпуск «Подлодки» — про личный бренд разработчика. Ребята там обсуждают разные каналы общения с аудиторией: доклады, подкасты, соцсети, блоги.

Я со многим не согласен. Почти со всем ツ Но если по докладам и подкастам Егору и компании явно виднее, то по блоггингу не могу промолчать.

Егор говорит:

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

Дальше ведущие обсуждают, что лучше, мол, использовать Medium, потому что это быстро, удобно и «из коробки идёт рекомендательная система».

Вот что я об этом думаю:

Вести блог на «Медиуме», «Хабре» или «Виси» — так себе идея. Это как работать «литературным негром» для ленивого богатого чувака, который вас в грош не ставит.

1. Всё, что вы пишете на коллективных блого-платформах, работает на благо владельцев этих платформ, а не на вас.
2. Читатели вынуждены кроме собственно статей «наслаждаться» рекламой, требованиями отключить блокировщики, включить оповещения, подписаться на платный тариф и прочей лабудой, которую подсовывает платформа (особенно отличается этим «Медиум»).
3. Однажды владелец платформы может решить, что вы нарушили третий подпункт двенадцатого пункта пятьдесят третьей страницы пользовательского соглашения — и выпилит учётную запись вместе со всем вашим добром.

А вот альтернатива:

Домен на год стоит 150₽. Облачный WordPress, к которому можно приделать этот домен, стоит 250₽ в месяц. Если жалко 250₽, можно взять Blogger или Tumblr — они бесплатные и тоже дают прикрепить собственный домен.

Времени на настройку потратите 20 минут, но это будет ваш блог и ваши статьи. Если решите потом переехать с Вордпресса на облачный Ghost или на стенделон — статьи прозрачно для подписчиков переедут вместе с вами — потому что всё на вашем домене, а не на домене блого-платформы.

Насчёт рекомендательной системы «из коробки». На «Медиуме» для русскозычных статей она просто не работает («Медиум» вообще презирает кириллицу, даже отображает каким-то мерзким шрифтом). «Хабр» и «Виси» действительно дадут большой охват, но говорить о каком-то личном бренде не приходится — вы навсегда останетесь одним из тысяч безликих юзернеймов, вне зависимости от популярности статей.

А если «Медиум» так дорог вашему сердцу — делайте на нём репосты избранных статей из своего блога. На «Хабре» и «Виси» тоже можно, только не один-в-один, а вариации на тему.

Потратьте 150₽, купите домен, правда.

P.S. Подписывайтесь на «Подлодку», она классная. Ребята когда-то делали вид, что они про мобильную разработку, но, к счастью, одумались, и теперь записывают подробнейшие разборы всяких айтишных тем.

Допустим, вы пишете программу, которая обрабатывает заявки разных типов — идеи, вопросы и проблемы:

from collections import namedtuple
Request = namedtuple("Request", ("type", "text"))

requests = [
  Request(type="question", text="Как пасти котов?"),
  Request(type="problem", text="Бакланы портят стадион"),
  Request(type="idea", text="Переводчик с лисьего на русский"),
  Request(type="problem", text="Кот крадёт электричество"),
  Request(type="problem", text="Мыши похитили 540 кг марихуаны"),
  Request(type="idea", text="Холодильник с таймером"),
]

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

stats = {}
for req in requests:
  if req.type in stats:
    stats[req.type] += 1
  else:
    stats[req.type] = 1

stats
{'question': 1, 'problem': 3, 'idea': 2}

Прямо больно смотреть на этот if, верно? Лучше воспользоваться методом dict.setdefault(). Но как по мне, он тоже уродливый, поэтому ещё лучше — collections.defaultdict:

from collections import defaultdict
stats = defaultdict(lambda: 0)
for req in requests:
    stats[req.type] += 1

dict(stats)
{'question': 1, 'problem': 3, 'idea': 2}

А совсем хорошо — collections.Counter:

from collections import Counter
stats = Counter(req.type for req in requests)

dict(stats)
{'question': 1, 'problem': 3, 'idea': 2}

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

Если в программе есть настройки, хорошо предусмотреть для них умолчательные значения. Так всё будет работать «из коробки», а в конфиг полезут только те, кому это действительно надо.

Допустим, настройки по умолчанию мы сложили в словарь:

DEFAULTS = {
  "name": "Frank",
  "species": "pigeon",
  "age": 42,
}

А пользовательские настройки лежат в settings.ini. Их можно считать функцией load_settings(), которая тоже возвращает словарь.

Вопрос: как получить актуальное значение того или иного свойства?

Так себе способ:

custom = load_settings()

def get_setting_value(name):
  if name in custom:
    return custom[name]
  else:
    return DEFAULTS[name]

Способ лучше — воспользоваться collections.ChainMap:

from collections import ChainMap

# пусть custom ==
# { "species": "human" }
custom = load_settings()
settings = ChainMap(custom, DEFAULTS)

def get_setting_value(name):
  return settings[name]

get_setting_value("name")
'Frank'

get_setting_value("species")
'human'

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

settings["age"] = 33

custom
{'species': 'human', 'age': 33}

DEFAULTS
{'name': 'Frank', 'species': 'pigeon', 'age': 42}

Если программист привык писать код, как это делали наши пращуры со времён аграрной революции, то перечисления у него выглядят как-то так:

class PigeonState:
    eating = 0
    sleeping = 1
    flying = 2

PigeonState.sleeping
1

Конечно, у наших современников есть способ получше — enum.Enum:

import enum
class PigeonState(enum.Enum):
    eating = 0
    sleeping = 1
    flying = 2

PigeonState.sleeping.value
1

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

class PigeonState(enum.Enum):
    eating = 0
    sleeping = 1
    flying = 2
    
    # There is no way Frank is really doing that
    thinking = 1

PigeonState.thinking
<PigeonState.sleeping: 1>

Или добавлять свои атрибуты:

class PigeonState(enum.Enum):
    eating = (0, "Ест")
    sleeping = (1, "Спит")
    flying = (2, "Парит в небесах")
    
    def __init__(self, id, title):
        self.id = id
        self.title = title

PigeonState.flying.id
2

PigeonState.flying.title
'Парит в небесах'

А ещё можно:

• сравнивать по is вместо ==
• сортировать с помощью enum.IntEnum
• итерировать по значениям
• создавать динамически

В общем, енумы — однозначное добро.

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

Core-разработчик Питона Реймонд Хеттингер тоже это заметил, и поэтому в документации к каждому модулю стандартной библиотеки первым делом идёт ссылка на исходники этого самого модуля на гитхабе.

Если вы прочитали описание функции или класса, а вопросы остались — не стесняйтесь пойти в исходный код и посмотреть, как оно там устроено. Большинство модулей отлично написаны, код понятный, в меру откомментирован.

Чтобы создать хороший интерфейс, дизайнеру требуется:

• 80% здравого смысла,
• 19% знания предметной области,
• 1% дизайн-мышления, дизайн-систем, насмотренности и прочего, про что дизайнеры любят писать статьи на Медиуме.

То есть главное в дизайне — здравый смысл. Чтобы доказать это утверждение, я сделаю «редизайн» популярного приложения Zoom (замена скайпу для видео- и аудио-конференций) с позиции обычного здравомыслящего человека, не дизайнера.

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

1. Главное действие

Какое главное действие на основном экране приложения для конференций?

2. Как начать конференцию

Хьюстон, у нас проблемы: пользователь не закрыл с отвращением приложение, а ткнул в «Start meeting» на главном экране. Что делать?

3. Как включить звук

Кожаный мешок не сдаётся и нажал на «Start a Meeting» на предыдущем экране. Что делать?

4. Как всё-таки начать конференцию

Человечишка включил микрофон. Что ему предложить?

5. Как пригласить собеседников

Методом революционной интуиции юзер допёр, что надо нажать на «Participants». Что делаем дальше? Так далеко ещё никто не проходил.

6. Как всё-таки пригласить собеседников

Нам попался сообразительный засранец: он нашёл маленькую кнопку «Invite» и нажал на неё. Какие варианты предложим?

7. Поехали

Дизайнер: это было несложно, да?

Человек: дизайнер, ты реально упоротый.

⌘ ⌘ ⌘

Здравый смысл, ребята. Пользуйтесь им.

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

Посмотрим на питоновский модуль difflib, который помогал нам сравнивать строки:

• find_longest_match() находит самый длинный совпадающий кусок между двуми последовательностями и возвращает match — объект с совпадением и дополнительной информацией.
• get_matching_blocks() находит все совпадения между двумя последовательностями и возвращает список из match.
• get_close_matches() находит слова, сильнее всего похожие на переданное слово, возвращает список строк.

По отдельности вроде все названия хороши и понятны. Но я утверждаю, что это — говнокод:

• find_longest_match возвращает объект-match, как и следует из названия; и get_matching_blocks возвращает такие же объекты, хотя название намекает, что должны возвращаться какие-то blocks
• get_close_matches, судя по названию, должен возвращать match, как find_longest_match — но возвращает строки
• одна и та же по сути операция (поиск совпадений) в одном случае называется find, а в двух других — get

В результате уже на следующий день не вспомнить, кто как называется, без обращения к документации.

Уж на уровне одного модуля можно напрячься и сохранить единообразие? Я предложил бы такие имена:

• find_longest_match()
• find_all_matches()
• find_similar_words() или просто find_similar()

Мантра «There should be one — and preferably only one — obvious way to do it» из Zen of Python далека от реальности.

Все мы знаем, что в Питоне за долгие годы собрали аж три способа подстановки переменных в строку:

who = "Голубь Френк"
"%s постучался в стеклянные двери" % who
"{} постучался в стеклянные двери".format(who)
f"{who} постучался в стеклянные двери"

Но не все знают, что есть ещё и четвёртый способ — string.Template. Больше того, он ещё и может быть полезен иногда.

Например, если вам не нужны расширенные возможности вроде форматирования чисел или обращения к атрибутам внутри шаблона, а нужно тупо заменять строковые переменные на их значения. Да ещё и синтаксис подстановки отличается от стандартного:

CHANGEME:who постучался в стеклянные двери

Тут и пригодится string.Template:

import string
class OmskTemplate(string.Template):
    delimiter = "CHANGEME:"

template = OmskTemplate("CHANGEME:who постучался в стеклянные двери")
template.substitute({ "who": "Кот Джарвис"})

'Кот Джарвис постучался в стеклянные двери'

Если нужен ещё более извращённый синтаксис — например, ==!who!== — достаточно перекрыть атрибут класса pattern, указав в нём подходящее регулярное выражение.

Я очень люблю читать авторские телеграм-каналы. Авторские — это вроде блога: когда человек делится личным мнением или, ещё лучше, опытом.

К сожалению, большинство каналов не такие. Они постят ссылки на чьи-то чужие статьи и видосики, в лучшем случае добавляя короткий комментарий от себя. Это так себе.

Самое дно — когда автор канала подключает бота и такой «ребята, ура, я теперь автоматически буду постить вам полезные ссылки». Чувак, кому нафиг нужны твои автоматические ссылки? От таких сразу отписываюсь.

А самые офигенные каналы — это @diysupport Александры Ширяевой (про техсаппорт) и @pmdaily Федора Борщева (про разработку сервисов). Эти ребята прям жгут, если темы вам близкие — очень рекомендую.

Ну и мой @ohmypy про питончик, конечно ツ

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

Например, такая статья:

text = """Голубь Френк прибыл в отель "Четыре сезона" с дружеским визитом. По сообщениям очевидцев, он сожрал в ресторане киноа прямо из тарелки гостя, а затем клюнул в глаз прибежавшего на шум официанта.

Френк прилетает в "Четыре сезона" каждый год. В прошлый раз мерзкая птица нагадила в ванну с шампанским в королевском люксе, лишив кого-то романтического вечера."""

Вы чистите текст от пунктуации, бьёте по пробелам и считаете слова. Вот топ-3:

[('френк', 2),
 ('четыре', 2),
 ('сезона', 2)]

Но погодите, разве правильно считать «четыре» и «сезона» разными тегами? Это ведь название отеля, лучше учитывать их как одно словосочетание. Тут-то и пригодится функция shlex.split() — она трактует словосочетания в кавычках как один токен:

# слегка чистим text, для краткости опускаю
import shlex
from collections import Counter

words = shlex.split(text)
words = [word for word in words if len(word) > 3]
Counter(words).most_common(3)

[('френк', 2),
 ('четыре сезона', 2),
 ('голубь', 1)]

Вот теперь теги что надо!

P.S. Вообще, shlex предназначен для разбора shell-подобных строк, так что если злая судьба заставит вас парсить bash-скрипты — вы знаете, куда смотреть.

На днях мы использовали метод SequenceMatcher.ratio() из модуля difflib, чтобы оценить сходство двух строк.

А что бы вы сказали, если узнали, что у того же класса есть ещё методы quick_ratio() и real_quick_ratio()? С описанием «возвращает верхнюю границу ratio довольно быстро» и «возвращает верхнюю границу ratio очень быстро»?

Я бы сказал, что это говнокод. Если бы коллега принёс такой код на ревью, я бы предложил подумать ещё ツ Либо ты нормально называешь эти методы, чтобы понятно было, когда какой использовать. Либо прячешь их в глубине модуля и не делаешь частью публичного API.

Конкретно в данном случае я бы сделал «быстрый» и «очень быстрый» методы приватными, потому что они нужны только для оптимизации работы других публичных методов difflib. Используются примерно так:

if matcher.real_quick_ratio() >= cutoff and \
    matcher.quick_ratio() >= cutoff and \
    matcher.ratio() >= cutoff:
    ...

Как вспомогательные методы — ладно. Но точно не в публичный интерфейс.

Если вы фронтенд-разработчик — пожалуйста, не отчаивайтесь! Это не приговор. Многие мои знакомые фронтендеры сумели отказаться от этой калечащей привычки и вернуться к нормальной жизни.

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

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

Вы ещё можете бросить фронтенд и стать адекватным человеком. Мы не осуждаем вас, мы здесь и готовы помочь. Не сдавайтесь, боритесь. Обратитесь к ближайшему Java, Python или C#-разработчику, чтобы узнать, как сделать первый шаг к отказу от джаваскрипта. Начните менять жизнь к лучшему прямо сейчас!

Наверняка вы знаете про функции pprint.pprint() и pprint.pformat(), которые красиво форматируют разные коллекции и словари.

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

Например, запросили вы апишечку и получили в ответ развесистый словарь:

rating = requests.get("https://www.cia.gov/the-world-factbook/top-dumbest-animals").json()

Заглянем в него, не погружаясь в детали:

import pprint
pprint.pprint(rating, depth=3)

{'leaderbord': [
  {'details': {...}, 'name': 'Голубь Френк', 'position': 1},
  {'details': {...}, 'name': 'Лисица Клер', 'position': 2},
  {'details': {...}, 'name': 'Попугай Питер', 'position': 3},
  {'details': {...}, 'name': 'Свинка Зои', 'position': 4},
  {'details': {...}, 'name': 'Макака Лукас', 'position': 5}],
 'name': 'Самые тупые животные'}

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