Python весьма неплох для стряпанья скриптиков. Однако если однотипных скриптиков становится много и появляется общий код, то тем или иным образом возникнет проблема с организацией папочек так, чтобы импорты работали нормально. Классический пример — импорт из “соседней” папки.

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

1. Вы все делаете неправильно, так писать код нельзя, срочно поменяйте свою структуру папок. Гвидо проклинает таких, как вы.
2. Вы должны правильно настроить virtualenv, сделать одну из ваших папок пакетом и установить ее (как и любой пользователь ваших скриптов).
3. Вы можете запускать свои скрипты как модули с флагом -m. Успехов вам в добавлении этого в мутные инструкции по запуску и в слежении за тем, чтобы при автоимпорте всех скриптов из папки ничего не сломалось.
4. Вы можете грязным хаком добавить нужный путь в sys.path, например, так:

   sys.path.append(str(pathlib.Path(__file__).resolve().parent.parent))
   

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

Подробнее про импорты можно прочитать тут и тут.

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

Отличный сайт для изучения разных социальных и не очень проблем в игровом формате: https://ncase.me/.

Самая популярная — игра про доверие (базовая теория игр included!).

Еще можно отметить игры про системы голосования и сегрегацию.

В игровом формате можно узнать не только про что-то связанное с математикой, но и, например, про тревожность или про распространение ненависти.

Если написать такую программу

fun main(args: Array<String>) {
    println("Hello, dudes!")
}

и скомпилировать ее через kotlinc 1.kt -include-runtime -d hello1.jar, то при запуске через java -jar hello1.jar получим приветствие. Однако если то же самое сделаем с эквивалентным кодом

object Main {
  @JvmStatic
  fun main(args: Array<String>) {
    println("Hello, dudes!")
  }
}

то результат будет уныл:

no main manifest attribute, in ./hello2.jar

Почему не генерируется манифест можно посмотреть в исходниках компилятора. Через пару прыжков выходим на MainFunctionDetector, где, продравшись через условия, можно понять, что главными считаются только top-level функции, и в манифест Main-Class добавляется только в первом случае. Хотя казалось бы, раз уж есть код для поиска главного метода, то ничто не мешает проставлять Main-Class во всех случаях. Звучит довольно низкоуровнево, ведь у всех есть система сборки или IntelliJ на худой конец, но это все-таки баг.

Занимательный тест: https://computers-are-fast.github.io

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

В продолжение предыдущего поста. Чтобы иметь возможность сериализовать dataclass в JSON, можно сделать что-то вроде трейта и примешать его к датаклассам.

from dataclasses import dataclass, asdict

class Serializable:
    def _asdict(self):
        return asdict(self)

@dataclass(frozen=True)
class Person(Serializable):
  name: str
  age: int

p = Person("Jeshua", 33)

requests.get("http://httpbin.org/anything", json=p).json()

Эта штука вам вернет…

TypeError: Object of type Person is not JSON serializable

Но если поставить модуль simplejson, который можно считать девелоперской версией встроенного json, то ответ будет нормальным:

{... 'json': {'age': 33, 'name': 'Jeshua'}, ...}

Как же это работает? Во-первых, в модуле requests есть развилочка:

try:
    import simplejson as json
except ImportError:
    import json

Во-вторых, в модуле simplejson есть встроенная поддержка namedtuple: если у класса есть метод _asdict, то он будет вызван для получения словаря, из которого потом будет сделан JSON. Т.е. с simplejson namedtuple можно просто передавать как параметр в dumps без лишних телодвижений. А благодаря Serializable датакласс маскируется под namedtuple.

Еще в древнем 2.6 были namedtuple:

from collections import namedtuple

Person = namedtuple("Person", "name age")
p = Person("Jeshua", 33)
print(p.name)

Они позволяли обращаться к полям по имени и были иммутабельными. Однако создание было не очень красивым.

Потом в 3.5 появились типы:

from typing import NamedTuple

class Person(NamedTuple):
  name: str
  age: int
p = Person("Jeshua", 33)
print(p.name)

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

Наконец, в 3.7 появились dataclasses:

from dataclasses import dataclass

@dataclass(frozen = True)
class Person:
  name: str
  age: int

Казалось бы, то же самое, но есть нюансы: можно сделать мутабельными, можно организовать наследование, значения по умолчанию, сравнение более безопасное и еще пара фич. В общем, чтобы не запоминать 3 штуки, проще запомнить dataclasses и использовать везде их.

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

Однако доклад все равно полезный — в нем и кратенько про git и github flow рассказано, и проблема более-менее четко обозначена, и показаны варианты решения с плюсами и минусами.

1. Скачиваем релиз, распаковываем.
2. Запускаем kotlinc-native -help:

Error occurred during initialization of VM
Could not reserve enough space for 3145728KB object heap

3. Офигеваем от того, что этой штуке нужно 3 гига, запускаем с ограничением:

_JAVA_OPTIONS="-Xmx256M" kotlinc-native -help

4. Делаем 1.kt с чем-то похожим на котлиновский код:

fun main() {
  println("https://t.me/minutkaprosvescheniya/120")
}

5. Пробуем скомпилировать:

_JAVA_OPTIONS="-Xmx256M" kotlinc-native 1.kt -o 1

6. Офигеваем от того, что надо скачать “немного” зависимостей — 600 мегабайт (в 2000-х за такое расстреляли бы).
7. Офигеваем от того, что виртуалка у нас немного старая, i386, и kotlin-native поддерживается для arm32, win x86, watchOs x86, wasm32, MIPS, умных часов, но не для linux 32-bit, мол никому не надо — тебе надо, ты и делай.
8. Повторяем шаги 1-6 для компа поновее.
9. Офигеваем от того, что нельзя никак убрать расширение .kexe, потому что “это хороший способ идентифицировать файлы”.
10. Запускаем ./1.kexe, получаем результат.
11. Продолжаем офигевать от зрелости технологии.

Когда-то давно я думал, что root всемогущ и может убить любой процесс. Однако если процесс находится в состоянии Uninterruptible Sleep (оно же D), то он может так конкретно повиснуть, что поможет только перезагрузка, о чем даже в отделе травили страшилки на вечер пятницы:) А происходит это из-за того, что процесс ждет I/O и на сигналы не реагирует. И если что-то пошло не так, то так он и будет висеть до следующей перезагрузки, несмотря ни на что (такое было на проде).

В новом дивном мире ты просто редеплоишь докер-контейнер в кубере, но на нем свет клином не сошелся.

Подробнее про состояние процессов можно почитать в статье.

Самые банальные варианты включают в себя:

1. Тестирование на тестовом стенде (для особых извращенцев — на общем стенде, для супер-извращенцев — резервирование ресурса путем устных переговоров с коллегами, ну а у темных властелинов тестовый стенд — это прод).
2. Тестирование с БД, которая разворачивается локально (возможно даже сама, возможно в докер-контейнере).
3. Тестирование с in-memory аналогом.

С первым пунктом все понятно, а вот между другими двумя надо думать.

С одной стороны, завязываться на реализацию БД как-то странно, особенно с учетом того, что вряд ли к базе идет обращение напрямую, а не через ORM и/или DSL, и может еще и через liquibase. С другой — эти абстракции дырявые, и тот же liquibase поле с типом TEXT создаст как TEXT (он же VARCHAR) в Postgresql, но как CLOB в H2. Вдобавок, у различных СУБД есть свои “особенности”, от которых не всегда получится абстрагироваться — помню как года 4 назад во времена импортозамещения у меня пригорело от того, что Oracle не различает пустую строку и null. Вдобавок всякие статьи говорят о том, что не-не, нельзя делать unit-тесты c in-memory H2, если у вас на проде Postgresql, у вас прод сгорит и вообще мы все умрем.

В моем идеальном мире все СУБД и прослойки для общения с ними написаны нормально и такие проблемы не должны возникать. В чуть менее идеальном — эти отличия несущественные и легко проверяются интеграционными тестами, если надо поддерживать несколько СУБД, или влияют только на производительность, но не на интерфейсы/поведение.

Но этой заметки не было бы, если бы не потекшие абстракции: при обновлении H2 столкнулся с проблемой, что они решили кидать исключение про то, что не поддерживают индексы на CLOB поля (хотя раньше просто ничего не делали). И вот сошлись звезды в лице связки liquibase + H2, и несмотря на то, что никакие нестандартные вещи не использовались, все поломалось. Конкретно в этом кейсе удалось извернуться, но ситуация насторожила: получается, что SQL не такой уж и стандарт…