Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Ошибка случается, например, если ленифицируемый класс не переопределяет стандартный object.__repr__, который изменяется от запуска к запуску
Нужно детектить хотя бы регекспами стандартные неподходящие __repr__ и делать про это warning.
Нужно для типов, которые встречаются в первый раз, пробовать создать дважды один и тот же объект и сравнивать их __repr__ и хеши. Если результаты получаются разные — снова warning.
Ложноотрицательные ошибки приводят к тому, что ленификация не работает. Объект будет пересчитываться при каждом новом выполнении скрипта.
Можно запоминать место вычисления в дереве и прогонять одно и то же дважды. Если значения будут отличаться — warning. Это можно делать, например, в автоматически генерируемых автотестах для конкретного вычисления или при запуске с определенным ключом.
Репрезентация объекта (или переопределенная хэш функция) [..] совпадает с репрезентацией объекта другого типа.
Можно запекать тип значения рядом со значением в одной структуре. При встрече двух разных типов с одним хешем — warning.
В целом подход интересный. Спасибо.
Я, единственно что, использую warning на совпадение if obj.__class__.__repr__ is object.__repr__.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.
В целом, ввести дополнительные проверки можно, но я все-же полагаю, что это не задача библиотеки контролировать валидность входных данных. Можно понаписать множество тестов и все равно не покрыть всю область возможных ошибок.
Собственно, изначально я делал что-то подобное. Счел излишним. Выпилил всё, оставил только логику.
Это можно спрятать за отдельными необязательными опциями.
Это можно вынести в отдельную фичу — автогенерация автотестов.
То есть у вас есть ленивое вычисление и вы можете его запустить, а можете сгенерировать по нему параноидальный автотест. Пользователи его смогут запускать в пайплайне основного CI и своевременно увидят проблемы, причем на производительности вычислений это не скажется.
Это можно вынести в отдельную фичу — автогенерация автотестов.
То есть у вас есть ленивое вычисление и вы можете его запустить, а можете сгенерировать по нему параноидальный автотест. Пользователи его смогут запускать в пайплайне основного CI и своевременно увидят проблемы, причем на производительности вычислений это не скажется.
Не удержался, залез в код.
Скажите, почему вы используете лямбдами там, где можно использовать функции из модуля `operator`?
Ещё я бы завернул хэш-алгоритм в обертку для кодирования строк в utf-8, чтобы в тысяче мест не писать такое: «m.update(obj.__module__.encode(»utf-8"))"
Хочется отформатировать код по pep-8. Вы принципиально против него, или просто руки не доходили?
Скажите, почему вы используете лямбдами там, где можно использовать функции из модуля `operator`?
Ещё я бы завернул хэш-алгоритм в обертку для кодирования строк в utf-8, чтобы в тысяче мест не писать такое: «m.update(obj.__module__.encode(»utf-8"))"
Хочется отформатировать код по pep-8. Вы принципиально против него, или просто руки не доходили?
К сожалению, не знал про этот модуль. Я вообще не так много пишу на питоне. Попробую оптимизировать.
Про pep-8 знаю, хотя подробно его не изучал (опять же, не так много пишу на питоне). Потому форматирование такое, какое мне кажется удобным. Например, не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
`m.update(obj.__module__.encode(«utf-8»))` наверное стоит обернуть. В целом, не вижу особой разницы между этим и каким-нибудь `updatehash_string(m, obj.__module__)`.
Про pep-8 знаю, хотя подробно его не изучал (опять же, не так много пишу на питоне). Потому форматирование такое, какое мне кажется удобным. Например, не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
`m.update(obj.__module__.encode(«utf-8»))` наверное стоит обернуть. В целом, не вижу особой разницы между этим и каким-нибудь `updatehash_string(m, obj.__module__)`.
не вижу никакого смысла разбивать операторную околесицу по строчкам. Файл станет длинным и сразу же станет очень сложно что-либо в этом файле найти.
А вот тут вы не правы. В Питоне есть правильный способ писать код. Правила довольно строги и имеет смысл привыкнуть к ним, а не нести свои привычки из других языков. Если код писать правильно, то размер файла по числу строк не будет критичен, зато все будет прозрачно и понятно с одного взгляда.
При правильном разбиении кода на модули, классы и методы проблем с навигацией возникнуть не должно. А вот кучи плохо читабельных кусков через точку с запятой — это кошмар.
Прелесть PEP-8 в том, что пользуясь им вы сделаете свой код очень похожим на большую часть чужого кода. Это дорогого стоит, поскольку не нужно отвлекаться на стилистические различия.
В современных IDE есть замечательные линтеры и автоформаттеры, а для хардкорщиков, работающих в IDLE есть чудесная библиотека pep8. Если скормить её питоновский файл, она перечислит все его проблемы, связанные с оформлением по pep-8
Я согласен с тем, что общепринятое оформление — это хорошо.
Но есть исключения. Возьмем к примеру sgorsten/linalg (https://github.com/sgorsten/linalg/blob/master/linalg.h). Это плоская библиотека линейной алгебры для с++. Она читаема исключительно благодаря тому, что автор наплевал на общепринятое форматирование.
Постараюсь привести в соответствие с pep8 все, кроме операторов. Они мне пока еще в таком виде нужны.
Но есть исключения. Возьмем к примеру sgorsten/linalg (https://github.com/sgorsten/linalg/blob/master/linalg.h). Это плоская библиотека линейной алгебры для с++. Она читаема исключительно благодаря тому, что автор наплевал на общепринятое форматирование.
Постараюсь привести в соответствие с pep8 все, кроме операторов. Они мне пока еще в таком виде нужны.
Внес изменения в код. Использован модуль operator и добавлена функция updatehash_str.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Дисковое кеширование деревьев ленивых вычислений