Доступна библиотека urm.py с реализацией URM (UnRelational Mapper) для языка Python. Проект может оказаться полезным, когда требуется сохранить какие-нибудь данные не в реляционной базе данных, а в нереляционном хранилище, таком как файловая система, архив, облачное хранилище, NoSQL-база...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54400
https://github.com/KOLANICH-libs/transformerz.py может работать как конвертер форматов json <-> yaml ... ?
Не из коробки. При композиции трансформеров композитный трансформер вызывает методы process в последовательности композиции, а методы unprocess - в обратном порядке. Для схем сериализации по умолчанию process обозначает парсинг, а unprocess - сериализацию. Поэтому скомбинировать yamlSerializer с jsonSerializer напрямую нельзя.Есть несколько опций
1. можно написать Invertоr, который просто поменяет местами входные и выходные метаданные + process/unprocess.
2. Можно не писать Invertor, а просто создать трансформер вручную, это всего несколько строк: https://github.com/KOLANICH-libs/transformerz.py/blob/master...Но надо помнить о последствиях - будет путаница. Сейчас все трансформеры "направлены" так, чтобы process шёл от "диска" к "памяти", и программист может на это полагаться. Если этот инвариант нарушить, то на это свойство полагаться уже будет нельзя, придётся помнить, какой трансформер куда направлен. Поэтому операции инверсии из коробки и нет.
Теперь "правильное решение":
3. можно разбить процесс на 2 стадии, сериализация и десериализация. Пишете класс, он принимает 2 трансформера, и имеет 1 метод "convert", он одним трансформером делает process, другим - unprocess на результате. Инварианты не нарушены, композиция присутствует.
Я вот тут битый час вас слушаю, случайно.
И вот скажу, что поэтому вас питонистов никто и не любит, потому что фремворки гигабайтные для парсинга XML в json придумываете, недорого. Ни вас ни жаваскриптеров.
XML для чтения машинами и человеку неудобен. XSLT - вкус мазохиста.Есть люди попроще, которым просто работать надо. Без экзерсисов на XSLT.
этот чудо-маппер написал чувак, ранее написавший т. н. "Issuer" - https://www.opennet.dev/opennews/art.shtml?num=53420Причем новость про т.н. "Issuer" от июля прошлого года, а в репе ровно один коммит от декабря того же года, что говорит о том, что он всегда подчищает историю коммитов, чтобы не было видно, что изменилось.
>что говорит о том, что он всегда подчищает историю коммитов, чтобы не было видно, что изменилось.Я обычно подчищаю историю коммитов (просто коммичу с --amend), но не чтобы не было видно, а потому что история коммитов не особо нужна, когда автор один (когда авторов много, она используется для сохранения инфы об авторстве, чтобы потом устраивать копирайтные разборки), она только место занимает и приводит к тому, что репозиторий дольше клонируется, и вдобавок, захламляет вид в гуевых фронтендах. Тебе реально интересно всё то говно и переделки (а их было много, и коммиты шли как можно чаще, у Notepad++ есть привычка иногда падать на ctrl+s, и при этом стирать редактируемый файл), которые были в процессе разработки этой либы? Многим проектам не помешало бы выкинуть историю, что бы уменьшило размер их репозиториев намного.
Зачем тебе коммиты тогда, чудила? Сохраняй в архивы годмесяцдень_1, 2, 3 и не захламляй больше мой гитхаб говнорепами
Коммиты нужны для сохранения полезной истории. Для возможности выборочного переноса изменений. Для пояснения в большой группе кто что когда сделал, чтобы спросить объяснений.Львиная доля коммитов может быть схлопнута в один. Когда автор один, все коммиты могут быть схлопнуты в один коммит на одну версию релиза.
> история коммитов не особо нужна, когда автор одинОшибочное суждение. История коммитов нужна не только разрабам, но и пользователям. Простой жизненный пример: множество пакетов в Fedora сопровождаются ровно одним человеком. По твоей логике, история там "не особо нужна". Но вот если я вижу в пакете строки, которые меня смутили, я жму Blame -- и вижу, что они были добавлены в ответ на какую-то багу (ссылка на баг -- в сообщении коммита). В больших крупных проектах Blame так и вовсе лучший друг разработчика и используется отнюдь не "для копирайтных разборок". Можешь даже считать гит "системой документирования изменений кода", где можно подсмотреть у "автора-одиночки" или коллеги, как именно он единым коммитом реализовал какую-нибудь штуку и в какие файлы ему для этого потребовалось внести изменения.
А уж пользователями "Issuer" должны были бы стать другие разрабы, умеющие в гит. И вот в июле кто-нибудь бы подключил себе это, а в декабре - сюрприз! - не ясно, что изменилось и изменилось ли вообще, т.к. автор зачем-то экономит байтики в инфраструктуре гитхаба. Доверия это не внушает, прозрачности не добавляет.
> всё то г_вно и переделки (а их было много)
А это лишь характеризует тебя как не очень дисциплинированного разработчика. Взялся реализовывать фичу -- реализуй ее до конца и закоммить. Если фича крупная и занимает несколько дней -- коммить каждый чих в отдельной ветке, но в master все равно сливай в виде ровно одного коммита, затем переходи к следующей задумке в порядке очередности.
>И вот в июле кто-нибудь бы подключил себе это, а в декабре - сюрприз! - не ясно, что изменилось и изменилось ли вообщеВ инструкции к Issuer явно написано, что рекомендуется делать свой форк, и его уже прописывать:
> # it is recommended to use an own fork
А если есть свой форк, то, что изменилось, определяется следующим образом: клонируется свой форк, клонируется апстрим, средствами гита делается дифф.
Также наличие форка защищает от ситуации как с одним из пакетов npm, когда пакет автор со злости удалил, и у многих сломалось.
>Простой жизненный пример: множество пакетов в Fedora сопровождаются ровно одним человеком.Сопровождается 1м человеком ≠ есть код только от одного человека.
>Но вот если я вижу в пакете строки, которые меня смутили, я жму Blame -- и вижу, что они были добавлены в ответ на какую-то багу (ссылка на баг -- в сообщении коммита). В больших крупных проектах Blame так и вовсе лучший друг разработчика и используется отнюдь не "для копирайтных разборок".
Я сам пользуюсь blame для отслеживания изменений в llvm. Но мои проекты - не llvm. Это обычно маленькие либы или инструменты, в которых может быстро и полностью разобраться 1 человек, прочитав весь их код. На данном этапе (1 разраб, 0 контрибьютеров, ~1 пользователей) не имеет смысла захламлять репозиторий, хотя бы потому, что после роста проекта этот хлам уже будет проблематично вычистить, не снискав тонны ненависти (но иногда лучше снискать тонны ненависти, чем оставить хлам, из-за которого проблемы постоянны (git - это не hg, чем больше коммитов - тем медленнее клонирование, а долгое клонирование очень неприятно, гораздо более неприятно, чем отсутствие истории), PRы на чужую историю легко перебазируются путём экспортирования в патчи, а потом git am).
>А это лишь характеризует тебя как не очень дисциплинированного разработчика. Взялся реализовывать фичу -- реализуй ее до конца и закоммить. Если фича крупная и занимает несколько дней -- коммить каждый чих в отдельной ветке, но в master все равно сливай в виде ровно одного коммита, затем переходи к следующей задумке в порядке очередности.
С момента разработки (проект разрабатывался специально для UniGrammar одновременно с ней, последнее изменение кода самой либы - июль) в него добавились только очень незначительные изменения: документация, тесты (да, я знаю, что я нарушил TDD, на начальном этапе у меня вместо тестов была UniGrammar, если она работала - значит ОК, как можно сообразить, эта либа была создана потому, что в UniGrammar вручную закодить и поддерживать весь зоопарк (а без зоопарка нельзя, UniGrammar создавалась изначально с целью объективного сравнения производительности различных генераторов парсеров с целью выбора и использования наилучшего (которым обычно является parsimonious (CoCo/py я не тестировал, ибо код для построения AST для него не написан), обгоняя даже ANTLR) ) было невыносимо), обновления шаблона (добавил CI через GitHub Actions). Захламлять этим историю не очень целесообразно на мой взгляд, особенно при 0 пользователях (с мая висит - и всем пофиг, потому что сложная штука для понимания, нужна только в редких случаях, вроде UG).
Автор, ты болван. (С)
Вам бы майкрософт попросить, чтобы открыли исходный код винды, да еще с историей изменений. Думаю они пошлют вас на три буквы, а вы как думаете? Или попросите Линуса не материться в рассылке :) А лучше, попрошу вас, будьте любезны, избавьте опеннет от таких коментариев.пс: Вам кобылу подари, а вы в зубы смотрите. Автор, никому ничем не обязан!
> Автор, ты болван. (С)Займитесь уже собственным унылом умом. А автору спасибо за подаренный труд, сделал и поступил хорошо.
Вам ещё учится и учится.1. Даже когда автор один, бывает надо вспомнить как оно раньше было и как было исправлено.
Бывает надо откатить изменения, потому что фикс поломал что то другое.2. Места оно занимает минимум. На скорость клонирования не влияет практически ни как, тк гит хранит большие паки где все запаковано. А клонирование вообще редкая операция.
Ну и жалобы из этой серии можно начинать когда у вас в репозитории больше гигабайта файлов лежит и хотя бы 50к коммитов.
Насчёт захламления вида - серьёзно!?3. Если у вас падает notepad++ и стирает файл то явно делате что то сильно не правильно, даже как вендузятник.
>Места оно занимает минимум. На скорость клонирования не влияет практически ни как, тк гит хранит большие паки где все запаковано.Предлагаю склонировать репозитории hg и гита. hg почему-то клонирует намного быстрее.
>А клонирование вообще редкая операция.Не такая уж и редкая. На каждом CI-пайплайне делается по несколько клонирований. И при установке пакета из гита тоже. Усугубляется тем, что в pipе так и не осилили ни поверхностные клоны (чтобы это хоть как-то оптимизировать приходится городить костыли), нни даже проверку версии в удаленном репозитории, чтобы не клонировать и не устанавливать лишнее.
>Ну и жалобы из этой серии можно начинать когда у вас в репозитории больше гигабайта файлов лежит и хотя бы 50к коммитов.
Просто скажу, что у меня есть причины агрессивно оптимизировать размер репозиториев. Вот фрагмент из моего конфига:
[core]
compression = 9[pack]
window = 4095
depth = 4095[gc]
aggressiveDepth = 4095
aggressiveWindow = 4095А всё потому, что я иногда делаю правки с телефона, а чем больше репозиторий - тем больше жжётся флешка. Да, я жмот, жлоб и жадюга, не могу бедным вендорам чипов и телефонов на их существование подать.
>Если у вас падает notepad++ и стирает файл то явно делате что то сильно не правильно, даже как вендузятник.Работать на 2 гигах оперативы, открывать файлы за 1000 строк кода ... на 81 вкладке ... Кстати, на Linux 8 GiB не падал ни разу при сохранении, но падал много раз по OOM + адски тормозит на больших файлах + регулярно глючит на копировании в буфер, но это уже скорее всего глюки вайна.
Ни разу не видел чтобы хоть кто-то пренебрегал историей изменений.
Какой репозиторий то?
на 10мб и 1к коммитов - там разница будет секунд 5-10 в худьшем случае.Для CI клонирование одна из самых быстрых операций, для таких мелких репозиториев.
Я рад за вас и ваш конфиг, но как минимум compression = 9 тут практически бесполезен, это огромный перекос в сторону жора проца с минимальным профитом по размеру.
Опять же, вы можете делать правки хоть в бумажном блокноте, почему вы думаете что ваши пользователи должны от этого страдать?Я даже не знаю, продайте мобилку и докупите ещё 2 гига в свой компьютер. Или на свалке поищите, такой хлам уже повыбрасывали.
Опять же, почему notepad++ а не pycharm или ещё какая вменяемая IDE для петонистов!?
В общем даже kate/geany и то интереснее будут на линуксе то.
Пожалуй, просто оставлю это здесь:
https://github.com/lizardfs/lizardfs/commit/d61a93e397f56923...
Тут все прекрасно - и фикс, и та "проблема" которую он фиксит, и то что километр копипасты перемешан с одной строкой реального исправления (найди ее, для тренировки ;-) и причина, вызвавшая этот километр опасных (ибо копипаста и где-нибудь _обязательно_ промазали) изменений в и так неизлечимо больном коде.И да, на самом деле это три комита. Раздельных.
"даже когда автор один" кончается ровно в тот момент, когда ты где-то засветил ссылку на свой репо. С этого момента в твоем коде вынуждены разбираться другие - даже если он нахрен никому не нужен.
"ваша история никому не нужна" - это только для lkml и тому подобных помоек. Где действительно никто не собирается потом в твоем коде ничего исправлять.
Люди, вы чё?! Как это пропустили и оно у меня в ленте оказалось? Сегодня не первое апреля, и не первое января кончайте бухать!
Ух ты, корчеватель!
> Проект может оказаться полезным, когда требуется сохранить какие-нибудь данные в нереляционном хранилище, таком как файловая система, архив, облачное хранилище, NoSQL-база.А почему бы сразу не сохранять данные там где потребуется без сторонних библиотек?
Зачем делать просто если можно сделать сложно ?
Я поначалу так делал. Пришлось слишком много почти одинакового кода написать. А потом весь этот код править при улучшении UniGrammarRuntime и UniGrammar, не забывая о нюансах каждого отдельного бэкенда. Слишком трудоёмко. После разработки и внедрения этой либы стало намного легче.
Про абстрагирование не слышал?
Вроде эта либа как раз про абстрагирование. Правда, её назначение для меня ещё туманно. Но это потому, что таких задач у меня ещё не было)
Автор малость того, спасайся кто может :)
Прям не новость, а целый тьюториал...
Ну я по нему новость и писал.Вот полная версия: https://nbviewer.jupyter.org/github/KOLANICH-libs/urm.py/blo...
Здраствуйте. Я, Кирилл. Хотел бы чтобы вы сделали игру, 3Д-экшон суть такова... Пользователь может играть лесными эльфами, охраной дворца и злодеем. И если пользователь играет эльфами то эльфы в лесу, домики деревяные набигают солдаты дворца и злодеи. Можно грабить корованы... И эльфу раз лесные то сделать так что там густой лес... А движок можно поставить так что вдали деревья картинкой, когда подходиш они преобразовываются в 3-хмерные деревья[1]. Можно покупать и т.п. возможности как в Daggerfall. И враги 3-хмерные тоже, и труп тоже 3д. Можно прыгать и т.п. Если играть за охрану дворца то надо слушаться командира, и защищать дворец от злого (имя я не придумал) и шпионов, партизанов эльфов, и ходит на набеги на когото из этих (эльфов, злого…). Ну а если за злого… то значит шпионы или партизаны эльфов иногда нападают, пользователь сам себе командир может делать что сам захочет прикажет своим войскам с ним самим напасть на дворец и пойдет в атаку. Всего в игре 4 зоны. Т.е. карта и на ней есть 4 зоны, 1 - зона людей (нейтрал), 2- зона императора (где дворец), 3-зона эльфов, 4 - зона злого… (в горах, там есть старый форт…)Так же чтобы в игре могли не только убить но и отрубить руку и если пользователя не вылечат то он умрет, так же выколоть глаз но пользователь может не умереть а просто пол экрана не видеть, или достать или купить протез, если ногу тоже либо умреш либо будеш ползать либо на коляске котаться, или самое хорошее… поставить протез. Сохранятся можно…
P.S. Я джва года хочу такую игру.
Все ваши серьёзные пожелания и хотелки (я знаю, что они у вас есть, они у каждого есть) вам может иметь смысл отправить на https://github.com/open-source-ideas/open-source-ideas
https://store.steampowered.com/app/1377560/_/
Добавил, буду ждать.
Джва года?
Что эта трешачина делает в новостной ленте?!
Требую аргументировать, где конкретно трешатина, со ссылками на исходный код и вашими комментариями, что конкретно вам не нравится в архитектуре. Не тут, а в issue на GitHubе. Все ваши идеи по улучшению - туда же. Всё излагать на английском языке.Вы понимаете, что либы, подобные этой (по сути прослойка, не делающая ничего из прикладной логики, но облегчающая написание целевой логики), без нужды не проектируются (а это заняло довольно много времени, потому что я стремился сделать либу как можно более универсальной, чтобы когда передо мной в другом проекте встанет похожая проблема, то чтобы у меня уже было готовое решение)? И вы ведь понимаете, что если бы эта либа была уже написана кем-то другим (и найдена мною до написания моей либы), то я не стал бы переизобретать велосипед?
А излагать на английском языке - на таком же как в проекте - полуграмотном гугле транслете? Зачем же так себя мучить, потом тебе же переводить назад прийдется.
Сколько пользователей у данной очень нужной и полезной либы?
Как минимум 1. Любая либа начинает с 1 пользователя.
Как максимум - тоже.
Уж у твоих то либ юзеров миллиарды🤣🤣🤣
> Сколько пользователей у данной очень нужной и полезной либы?Эта либа решает проблемы хотя бы одного пользователя, чем выгодно отличается от тебя
> Требую аргументировать, где конкретно трешатина, со ссылками на исходный кодТрешачина прямо в тексте новости, из которого совершенно непонятно, что это за хрень и для чего она нужна. А *требовать* от занятых людей лезть в твой онокод — просто край наглости.
>Трешачина прямо в тексте новости, из которого совершенно непонятно, что это за хрень и для чего она нужна.Читать внимательно надо.
>Проект может оказаться полезным, когда требуется сохранить какие-нибудь данные не в реляционной базе данных, а в нереляционном хранилище, таком как файловая система, архив, облачное хранилище, NoSQL-база.
И? Чем это лучше, чем напрямую писать в файл?
Тут отвечать не надо. Лучше перечитай новость и исправь её так, чтобы стало понятно сразу при её прочтении. Не мне, а каждому. Мне уже из отсутствия у автора культуры работы с СКВ понятно, что к проекту даже приближаться не стоит.
>Требую аргументировать, где конкретно трешатинаТрешачина это текст новости созданный машинным переводом.
В машинном переводе не могло появиться слово "серилизовывать".
Можно я все-таки тут пару строк оставлю. Гитхаб давно уже не годится для свободной разработки, его слили жадные п-сы другим жадным п-сам.
По существу:
1. type annotations это трэш и захламление кода, тем более что типы автоматически не проверяются
2. хотелось бы видеть более ясные имена, вот, например, Dynamic - это скорее прилагательное, чем существительное, а для классов все же лучше существительные
Спасибо за отклик.>1. type annotations это трэш и захламление кода, тем более что типы автоматически не проверяются
Это прежде всего документация. Проверку типов через mypy в GitHub Action ещё не реализовал, не знаю даже, стоит ли захламлять пайплайн установкой mypy и его зависимостей ради проверки аннотаций на кадом коммите.
>2. хотелось бы видеть более ясные имена, вот, например, Dynamic - это скорее прилагательное, чем существительное, а для классов все же лучше существительные
Если честно, я там и задумывал прилагательное, выбор был между Dynamic и Deferred, со смыслом "вот есть какой-нибудь параметр (компонент пути, расширение), который мы сейчас не знаем и знать не можем, и вообще меняющийся в зависимости от объекта, и такой, который имеет смысл получать во время использования поля". Attr, Field, Prop - слишком обще и не отражающе суть IMHO. DeferredAttr - уже лучше, но длинновато. Но имена действительно нехорошие, несколько видов "отображателей" вызывают необходимость уточнять, какой отображатель где, а "стратегия" - тоже не очень говорящее название. Предложения по улучшению всегда приветствуются.
> Это прежде всего документация.Ее лучше в docstring запихать. ИМХО гораздо приятнее видеть чистое определение функции и затем исчепывающий Args: в docstring на человеческом языке чем нагромождение закорючек. И не забывайте про micropython.
Сначала выдумываем всякую ерунду, мучаемся с ней потому что кривое. Потом создаём монстролибы.
Ни секунды не сомневаюсь, что и десятой части от подобной ерунды не способен придумать, только с*рать на форуме таких же как ты дегенератов горазд
Эк автора бомбануло. Вы тут нас облагодетельтвовать решили вашим ненужным поделием, а мы не оценили?Ничего, бывает.
А я не автор, что еще раз подтверждает твою и 95% местных комментаторов-дегенератов тупость
Круто. Буду использовать.
Либа, может, и полезная, но текст новости так оформлять нельзя – он больше о том, как она работает, что умеет и как ею пользоваться, чем о том, зачем она нужна. Если лень описывать чем она полезна, то начинать стоило с примеров того, где она уже используется.P. S. Коляныч, привет тебе от бывшего участника лохерзталка! Периодически вижу тебя то тут, то там, всегда рад встретить знакомого человека :-)
>Либа, может, и полезная, но текст новости так оформлять нельзя – он больше о том, как она работает, что умеет и как ею пользоваться, чем о том, зачем она нужна. Если лень описывать чем она полезна, то начинать стоило с примеров того, где она уже используется.Проблема в том, что в либе используется слишком много слоёв абстракции, из-за чего взгляд на код человека, не знакомого со архитектурой либы, вызывает реакцию "WTF!?". Именно поэтому было решено сделать на этом акцент. Я считаю, что эта одна из проблем этой либы, но пока не знаю, как её правильно решить. Создания фасадов для типовых случаев в корне проблему не решает, но может облегчить пользование либой во многих случаях.
P.S. Мир тесен, а отрасль ещё теснее :) Рад, что с моими интернет-знакомыми всё в порядке.
P.P.S. Архангел, насколько мне известно, успел переехать в Польшу до активной фазы боевых действий на Донбассе.
Да, я слышал об этом.