vitus_wagner | Питонистическое.

From:

А модуле typing стандартной библиотеки есть NamedTuple, который делает то же самое, но помогает программе развалиться не в рантайме, а при статической проверке типов чем-нибудь типа mypy.

From:

phd_ru

Никак не могу понять — зачем в языке, ориентированном на duck typing, статическая типизация? И надо же, duck typing — единственное, чего mypy не умеет.

А кому нужны Жаба и ЦиПлюкПлюк — пусть идут в Жабу и т.д.

From:

avysk

mypy -- это вовсе не статическая типизация. Это проверка type hints (описанных в PEP 483 и 484) там, где они явно написаны, а где не написаны -- то и ладно. Duck typing это никаким образом не отменяет. Но оно иногда сильно помогает от идиотских опечаток, когда никакого duck typing не нужно, функция возвращает тапл из числа и строки -- а код, вызывающий эту функцию, перепутал строку и число местами.

Edited Date: 2020-01-05 10:55 pm (UTC)

From:

phd_ru

Я считаю, что от mypy больше вреда, чем пользы.

В тех проектах, где я видел использование mypy — отсутствие type hints выдавало ошибку. Не знаю, можно ли это отключить. Я вместо этого предпочитаю просто не иметь дела с mypy.

Как написать type hint "в этом месте мне нужен экземпляр класса, имеющий метод .read() без параметров, возвращающий строку"?

From:

yurikhan

В общем виде это называется «протокол»:

from typing_extensions import Protocol

class SupportsRead(Protocol):
    def read(self) -> str:
        ...


class MyReader:  # look ma, no inheritance
    def read(self) -> str:
        return 'hello world'


def test(reader: SupportsRead) -> None:
    pass

test(open('/dev/null'))
test(MyReader())
test(test)  # fails

В частном случае вообще может подойти typing.TextIO.

И да, я применяю mypy в боевом проекте. Польза от наличия аннотаций типов как документации для читателя/мейнтейнера кода настаёт при размере проекта больше 150 SLOC. А польза от mypy — примерно с той точки, когда проект естественным образом разделяется на несколько файлов.

From:

phd_ru

Спасибо! mypy таки дозрел до интерфейсов, замаскированных под именем протоколов. :-)

From:

avysk

> Как написать type hint "в этом месте мне нужен экземпляр класса, имеющий метод .read() без параметров, возвращающий строку"?

https://mypy.readthedocs.io/en/latest/protocols.html#protocol-types

from abc import abstractmethod
from typing import Protocol

class SupportsRead(Protocol):
    @abstractmethod
    def read(self) -> str:
        pass


def fun(something: SupportsRead):
    print(something.read())


class Good:
    def read(self) -> str:
        return "foobar"


class Bad:
    def read(self) -> int:
        return 42


fun(Good())
fun(Bad())

foobar.py:25: error: Argument 1 to "fun" has incompatible type "Bad"; expected "SupportsRead"
foobar.py:25: note: Following member(s) of "Bad" have conflicts:
foobar.py:25: note:     Expected:
foobar.py:25: note:         def read(self) -> str
foobar.py:25: note:     Got:
foobar.py:25: note:         def read(self) -> int
Found 1 error in 1 file (checked 1 source file)

Только не забывайте, что mypy -- это не статическая типизация, а проверка type hints там, где программист счёл их нужными. Если не написать type hints, ничего не будет -- например, если убрать "-> int" в описании класса Bad, ошибка исчезнет.

> В тех проектах, где я видел использование mypy — отсутствие type hints выдавало ошибку.

Я так понимаю, что Вы не видели использование mypy.

From:

phd_ru

Спасибо! mypy таки дозрел до интерфейсов, замаскированных под именем протоколов. :-)

Я видел использование mypy в нескольких крупных проектах и сильно его там невзлюбил. :-( Отсутствие type hints там везеде приводило к ошибкам.

From:

yurikhan

Выдавать ошибки на отсутствие аннотаций — это опция. И даже выключенная по умолчанию. Включить её принимает решение мейнтейнер проекта, в тот момент, когда проект уже достаточно аннотирован, или одновременно с решением аннотировать его весь.

В отдельных редких местах, где действительно применяется duck typing и кажется нецелесообразным прямо сейчас прописывать весь протокол, — ошибку можно заткнуть указанием аннотации Any (а лучше — отдельным типом, определённым как синоним Any, с TODO’шкой когда-нибудь это расписать).

From:

vitus_wagner

Когда при мне последние пару лет упоминают о тудушках, мне вспоминается файл
src/backend/storage/smgr/md.c из постгреса, в котором Настя Лубенникова нашла комментарий вида FIXME, написанный до её рождения. и так и оставшийся на этом месте.

From:

livelight

А почему именно set? Классическая реляционная алгебра не запрещает дубликаты tuples. Или в питоне "set" тоже их разрешает?

From:

phd_ru

Нет, в set дублей нет.

From:

vitus_wagner

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

Опять же, пересечение, объединение и симметрическая разность - очень полезные операции.

From:

yurikhan

Дубликаты в данных легко и непринуждённо образуются в результате неаккуратной реализации проекции.

managers = [e.manager for e in employees]
assert (sorted(m.name for m in managers) ==
        sorted(set(m.name for m in managers)))  # fails

Допущение «set of named tuples», впрочем, эту проблему снимает. Если, конечно, нас устраивает иммутабельность объектов.

From:

vitus_wagner

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

И в случае если данные у нас живут в памяти командно-строчного скрипта, ограничение на иммутабельность, как правило, не мешает. При старте прочитали с диска, обработали, построили рядом со старой новую копию, сохранили. (впрочем, в моем случае модифицировать придется не данные, а те объекты, о которых они. А метаинформацию в пригодном для чтении виде мне сгенерят внешние инструменты).

From:

livelight

Особенно это доставит радости, если надо делать агрегаты над проекцией. Например, count или sum.

From:

yurikhan

В моём случае результатом проекции был путь к файлу, над которым нужно было делать дорогостоящую (по процессору и I/O) обработку. И делать её один раз гораздо приятнее, чем 120 (хотя последнее и было безопасно).

From:

livelight

А вот для этого уже существуют взрослые СУБД: чтобы они сами думали, как выполнить 1 раз вычисления, которые, если в лоб выполнять написанное в запросе, придётся делать 120 раз. Но если автоматом схлопнуть все дубликаты, то проблемы будут уже с корректностью, а не производительностью.

From:

vitus_wagner

Любит народ у нас стрелять из пушки по воробъям.
Данные размером меньше мегабайта обрабатывать во "взросллой СУБД", одностраничные служебные записки писать в полнофункциональном офисном пакете и так далее.

From:

livelight

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

From:

vitus_wagner

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

From:

livelight

Дык, реляционная алгебра говорит, что результат должен быть одинаков. Потому что дубликаты она не удаляет.

From:

vitus_wagner

Это где это она такое говорит?

Вот я сейчас бегло пробежался по источникам, и там наоборот, говорят:

Основные свойства отношения:

В отношении нет двух одинаковых элементов (кортежей).
Порядок кортежей в отношении не определён.
Порядок атрибутов в заголовке отношения не определён.

а также

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

From:

livelight

Хм, и правда ж. Притом я ни минуты не сомневался, что "настоящая" алгебра отношений работает именно с такими множествами (где операция union all, например, смысла не имеет в принципе), но был уверен, что модель, с которой работает любая "реляционная" СУБД (с дубликатами, union all, select count group by и т.д.) как раз и называется "реляционной алгеброй"

From:

bowhill

Потому что на практике дубликаты в данных могут возникнуть только в результае ошибок ввода.

Это странное заблуждение, к тому же уникальность элементов набора -- это свойство области предметной области, а не области схемы БД.

Edited Date: 2020-01-06 07:58 pm (UTC)

From:

jno

А чего не сиквелобжектс имени бройтмана?
Или хочется свой бэкенд?

From:

phd_ru

Насколько я понял, Витусу нужны операции над структурами данных, похожие на реляционные. А не SQL'чная БД.

From:

vitus_wagner

sql-ная БД у меня даже там местами есть. Я правда, не попнял как ее заюзать.
Почему-то YUM кладет в каталог метаинформации файл .sqlite.gz. И вот как начать работать с ней, не распаковывая во временный файл на диске, я не придумал.
Поэтому парсю в xml.etree лежащий рядом xml.gz c той же информацией.
Благо вот его можно распактвывать сразу на вход парсера.

Но это - местами. Потому что рядом лежат дебиановские репозитории, где метаинформация лежит в виде yaml-подобного файла Packages и дублирующих его баз данных reprepro, и альтовские, где вообще хрен поймешь что там внутри ихних бинарных файлов. И то и другое приходится читать вызовом внешних процессов.

From:

vitus_wagner

Потому что SQL-ная БД - не единственный способ организвовать дурацкий поиск.

А использование ORM-ов над SQL-ем это вообще по-моему идиотизм.

Объекты - это очень слабая (потому как слишком универсальная) абстракция. Сама по себе реляционная модель - абстракция куда более мощная.

Хотя, конеяно, при таких объемах данных, как те, что я на питоне обрабатываю. можно и конструктор объекта на кажыдй кортеж звать - не жалко. Оверхед пренебрежимо малый получится. Там и сотни тысяч объектов не наберется. Но вот объекты hashable придется делать вручную. А named tuples они такие даром получаются.

В основном, конечно вопрос там в наиболее сладком синтаксическом сахаре. Как сделать код наиболее понятным для читателя.

From:

beldmit

Какая разумная альтернатива ORM-ам на уровне CRUD? Собирать запрос руками? Спасибо, нафиг.

From:

vitus_wagner

Ты знаешь, я довольно успешно занимаюсь программированием на протяжении уже более 30 лет, и при этом прекрасно обхожусь без знания аббревиатуры CRUD. ACID вот знаю, а без CRUD как-то обходился.

Но вообще если у тебя до уровня CRUD доехали объекты, то у тебя имеется какое-той fundamental design flaw. Вроде изначальной идеи php, где смешивается presentation и processing.

В стандартной model-view-controller парадишгме объекты должны оставаться на уровне view и в модель уже не лезть.

From:

beldmit

У меня типичный случай - view, где показывается несколько связанных объектов, соответствующих строкам из базы из разных таблиц. Если это редактура, то редактируются, как правило, поля одного объекта, и если нескольких, то контроллер разберёт, вытащит объекты и создаст запросы через объектный интерфейс. При этом ORM ещё и прикинет, надо ли ему обновлять единичный объект, если все старые значения совпадают с новыми, кажется.

From:

livelight

Термином CRUD обычно называют (по крайней мере, в кровавом тырпрайзе) манипуляции объектами уровня предметной области. А как оно там должно в базу ложиться - никто обычно не хочет писать руками этот аццкий бойлерплейт, все хотят переложить эту работу на ORM.

From:

bowhill

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

From:

kouzdra

Совершенно не обязательно. В OCaml (да и в Go) ничего такого особенно нет - соответствие объекта типу определяется исключительно фактической совместимостью по интерфейсу (кстати потому же в d Ocaml невозможен downcasting - для этого просто нет информации). Я кстати сильно подозреваю что упомянтое питоническое сперто как раз с Ocaml-евых объектов - там конечно оверхед не нулевой - там компилятор подбирает совершенный хеш, но подозреваю что по меркам питона - лишняя операция деления и лишняя косвенность - он нулевой

PS: Собственно в GCC 2.xx было подобное опытное расширение - сигнатуры, но не прижилось.

From:

bowhill

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

Edited Date: 2020-01-07 03:29 pm (UTC)

From:

kouzdra

"нормальный" синтаксис для чего-то типа sql придуман четверть века как - у какого-то корейца - три типа коллекций - set (неупорядоченное без дублей), mutliset (с дублями) и bags - с дублями и упорядоченностью.

Элементы - ну обычные довольно по функциональщие записи с именованными полями и "алгебраические" типы (union-ы с именованными вариантами) ну и естественно любые элементы сами по себе могут быть коллекциями и проч.

Все хитрые "запросы" тривиально пишутся в хаскелльного стиля сверточном синтаксисе.

При этом у модели есть прямая проектция в sql, хотя автор развивал и свою: поскольку информации о том "что надо" тут гораздо больше можно этим попытаться воспользоваться для оптимизации.

На деле оказалось просто мало кому интересно - все рисуют на sql и довольны как питоны :)

S	M	T	W	T	F	S
				1	2	3
4	5	6	7	8	9	10
11	12	13	14	15	16	17
18	19	20	21	22	23	24
25	26	27	28	29	30	31

Питонистическое.

Page Summary

Style Credit

Expand Cut Tags