Журнал Витуса

Встретил в питоновском коде вот такую констркуцию

    def __init__(self, version: str) -> None:
        self._version = str(version)

Что бы это значило? Если мы на этапе type checking отсекаем все что не str, зачем нам явным образом преобразовывать значение в строку?

Или это на случай если код будет запущен без предварительной статической проверки на типы?

вот тут nataraj в очередной раз ругает Python. Но по-моему зря ругает. К сожалению это общее правило. Ежели нечто у нас практически полезное, оно не может быть концептуально чистым. Его задача get things done, а не научить людей правильно мыслить. Нельзя вырезать узор на дереве инструментом, который не позволяет порезаться.

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

Вот у нас есть такие инструменты как pylint и perlcritic, которые находят разнообразные стилистические и не только погрешности. Я вообще взял себе за правило не коммитить питоновский код, не проходящий pylint и шелловский код, не проходящий shellcheck, Потому что если проанализируешь все ворнинги этих инструментов и некоторые потключаешь управляющим комментарием в конкретном месте кода, будешь по крайней мере уверен что код делает то, что ты имел в виду.

Но для целей (само)обучения нужен инструмент более высокого уровня. Который будет тыкать в нос "вот у тебя 80% кода написано в объектной парадигме, а здесь ты почему-то используешь чисто процедурное решение". То есть отслеживать применение известных парадигм и выдавать предупреждение где происходит переключение с одной на другую. Наверное, с помощью нынешних LLM такое уже можно написать.

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

Вышел новый питон. А в нем добавили pattern matching в стиле ML-ей, эрланга и Rust-а. Интересно, будет ли оно пользоваться популярностью, и если да - как скоро.

До сих пор как-то по-моему python развивался в противоположном направлении и высокоумные теоретические конструкции вроде lambda в нем норовили объявить deprecated. А тут вот полноценный pattern matching.

В остальном как-то ничего особо принципиально нового там не видно. Эх, избавиться бы поскорее от дистрибутивов с 3.2 и 3.4, чтобы можно было писать без огляднки на то что "вот это поддерижвается только с 3.5, а это - только с 3.8".

Кстати, у меня вот тут вчера на сервере опять запрос сертификтов с let's encrypt сломался. Потому что это было первое обновление сертификатов после апгрейда на bullseye. И acme_tiny вдруг внезапно обнаружила что просто "python" в системе больше нет. А догататься поискать python2 или python3 (оно вообще-то и с тем и с тем умеет) - шебанги у нас не настолько умны. Там тоже паттерн-матчинг нужен чтобы перебирать несколько вариантов интерпретатора (это я на днях наблюдал как jenkins java ищет на слейве. Не нашел что характерно, пришлось туда руками лезть и ставить).

Пришлось поставить на сервер специальный пакет python-is-python3. С ним сертифкаты обновились.

Задачку, запощенную вчера сумел решить только slobin.

В картинке содержался стеганографический текст, упакованный туда с помощью программы stepic. В процессе переписки в stepic-е был выявлен баг, который, впрочем, имеет простой воркэраунд.

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

Хорошо, что не Гугль

Интересно, а до 3.14.15 нумерация дойдет? Он же всё-таки пи-тон.

Написал себе новый скрипт для сортировки электронных книг. Уже не на shell через xmlstarlet, а на python с использованием xml.etree. Etree гораздо более требователен к валидности xml, поэтому на некоторые книги, особенно происходящие с Самиздата оно злобно ругалось, пришлось их немного руками править.

Что самое забавное, при корректной работе с namespace началась еще и чехарда с epub-ами. Выяснилось что имеющиеся у меня epub-ы используют аж три версии Doublin Core:

1. http://purl.org/dc/elements/1.1/
2. http://purl.org/dc/elements/1.0/
3. http://purl.org/metadata/dublin_core

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

Правда моя малая библиотека (которая ранее синхронизировалась со смартфоном) в таком виде не лезет в 4 гига. Надо либо не копировать на электронную книгу pdf и djvu, их все равно читать с ее экрана неудобно, либо проредить fb2. А то там у меня полно вещей, которые я начал читать, а они не пошли.

С другой стороны, наоборот, хочется приделать раскладывалку по каталогам по именам авторов и к pdf и djvu тоже. Правда, там будет общая засада с epub - имена авторов в метаинформации этих форматов, пишут как попало, и надо как-то объяснить скрипту, что "Первушин Антон Иванович" это

<last-name>Первушин</last-name>
<first-name>Антон</first-name>
<middle-name>Иванович</middle-name>

а вот Ursula leGuin это

<first-name>Ursula</first-name> 
<last-name>leGuin</last-name>

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

Выяснил что в стандартной библиотеке питона модуль collections, а в нем функция namedtuple. Позволяющая генерировать наборы данных с именованными полями и нулевым оверхедом. Более того named tuples - hashable, т.е. могут использоваться в качестве индекстов dict или элементов множества. И их очень удобно создавать из списков, dictionaries и тому подобных конструкций.

Теперь хочу реализацию операций реляционной алгебры над set of named tuples.

Поразвлекался еще тут немного с не самым мейнстримным календарным софтом - vCalendar plugin к claws-mail
и calcurse.

Задача, которую хочется решить - это обеспечить нормальную синхронизацию между андродидным календарем и десктопным с использованием своего caldav сервера (в качестве которог у меня radicale).

То есть получается следуюая картина:

Есть vdirsyncer, который синхронизирует локальный ics-файл с сервером, есть андроидные устройства на которых тоже все впорядке.

vCalendar plugin умеет импортировать ics. И даже автоматически его обновалять. В режиме чтения все нормально.
Но вот создавать новые события он будет не в импортированном календаре а в своем собственном (они выглядят в дереве папок как две соседние папки внутри vCalendar).

Он умеет экспортировать свой календарь в .ics-файл. Но в другой. И даже вызывать указанную программу после экспорта. И при этом:

1. Делает его нечитаемым для питоновского модуля vobject, на базе котрого сделан radicale. Путем добавления туда некоторых полей с датой 0000000T000000 на которые питон весьма обоснованно ругается "не бывает нулевого месяца".
2. экспортирует не только новые события но и те, которые были эксполртированы.
3. Таймзону ставит GMT.

Следовательно, если я хочу обратно засинхронизировать события, измененные в claws-mail в radicale, мне нужно
0. Перед разбором средствами модуля vobject удалить поля с некорректной датой.
1. Выцепить из экспортированного файла новые события
2. Поменять им временную зону на ту, которую использует radicale
3. Скопировать их в тот календарь, который синхронизирует vdirsyncer.

В принципе все это на питоне через тот же vobject делается в два экрана. Но может быть лучше взять исходники плагина и поправить. (хотя это -то придется делать на C++).

Что касается calcurse, то при всех его симпатичных свойствах он использует собственный формат хранения, а не ics. И при повтороном импорте изменившегося ics-файла дублирует события - отфильтровать по uid не догадыватеся.
Зато его можно повесить обработчиком mime-тип text/calendar в текстовый почтовый клиент вроде mutt.
Но только если этот клиент у вас единственный и ни с чем синхронизировать его вы не хотите. Или по крайней мере все остальные календари будут read-only.

Возникает мысль взять питоновские модули curses и написать программму с интерфейсмо в точности как у calcurse, но использующую в качестве backend-хранилища ics-файл, синхронизируемый vdirsyncer-ом.

https://pypi.org/project/fstrans/

В основном ради того, чтобы научитсья пользоваться setuptools. Хотя сам модуль в общем вполне практически полезный. Для себя делал. Базовую идею я придумал еще во времена Communiware, где картинки хранились на диске, а текст в базе данных, и требовалось сделать чтобы картинкам можно было сделать rollback. Тогда соответствующий код, конечно же был на перле написан, а не на питоне.

Сейчас использую этот модуль для работы с репозиториями пакетов. Поэтому оно умеет не только коммиты-роллбэки но и сериализацию доступа к дереву файлов.

И таки да, test suite запускается штатными средствами setuptools. В distutis, когда я там делал поддержку запуска test suite для ctypsecrypto, все руками приходилось делать.

P.S. Надо бы найти время и переписать setup от ctypsecrypto на setuptools, а заодно окончательно починить там работу с бинарными данными в 3-м питоне.