LINUX.ORG.RU

Организация типизированных (в т.ч. типы пользователя) данных с комментариями в json?

 ,


0

6

Сабж.

В python есть pickle который хранит в т.ч. типы пользователя и автоматически импортит модули при десериализации, но pickle какой то маргинальный стал (чехарда с форматами и невнятные перспективы), хочется уйти на json. Кроме того pickle все равно не умеет хранить комментарии из коробки.

Нужно сохранять и загружать вот такое:

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

  2. ключи в исходных данных гарантированно текстовые отвечающие требованиям к питоньим идентификаторам.

  3. Типы параметров — все что есть в json из коробки (числа, строки, списки, словари) + что то пользовательское, м.б. сложное и требующее импорта сторонних модулей при восстановлении.

  4. некоторые из параметров могут быть снабжены комментариями (комментарий это строка)

  5. желательно что бы комментарий лежал рядом с параметром для улучшения читабельности .json - файла глазами.

Интересна не техника записи/чтения в коде, интересна сама структура данных.

Понятно что список импортируемых модулей можно хранить в каком то списке на верхнем уровне.

Можно сделать две параллельных структуры с типами и комментариями, но выглядит как извращение:

[{ 'a':1, 'b':2.5, 'c':[1,2,3]},
 {'c':'myvector.myvector3D'},
 {'a':'длина баскетбольной площадки', 'c':'куда бросать мяч'}
]

Можно загонять тип в имя параметра 'myvector3D c':[1,2,3], можно рядом с параметром класть какую то информацию '@c':['myvector3D', 'куда бросать мяч'] — но это все работает только если параметры лежат в словаре, скорее всего так и будет но что то может поменяться.

В общем много вариантов но хороших я не вижу;-(

@annulen

★★★★★

Последнее исправление: AntonI (всего исправлений: 1)

Не очень понятно назначение такой штуки.

Если оно нужно для сериализации/десериализации данных для передачи/хранения, то нафига там комменты? Может, отказаться от части требований и поискать среди готовых библиотек? Допустим, serpent или marshmallow ?

А если комменты таки нужны, то это больше похоже на конфигурационные файлы. Может, тогда toml взять (с какой-нибудь из готовых либ), и не пытаться думать о конфигурации как о сериализованном объекте?

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Не очень понятно назначение такой штуки.

Хранение результатов расчетов. С одной стороны расчеты разные (со временем даже расчеты по одному и тому же проекту могут меняться), поэтому нужны комменты.

С другой стороны это именно сериализация/десериализация.

AntonI ★★★★★
() автор топика

В любом же случае надо будет делать два зеркальных метода - сериализацию и десериализацию? Какая разница, какая будет структура, если она только в этих методах будет использоваться и больше нигде?

PeleWin
()
Ответ на: комментарий от AntonI

То есть ты собираешься импортировать старые данные после того, как код был существенно изменен, и вместе с кодом могли поменяться состав/структура данных. Это значит, что при импорте тебе придётся преобразовывать старые данные в новый формат (переименовывать и перемещать поля, трансформировать значения полей), рожать откуда-то значения для новых (ранее не существовавших) полей. Тот ещё геморрой. На первое место тогда выходит наличие явной схемы данных и валидация её при каждой загрузке/выгрузке данных. Чтобы во-первых при разработке был стимул эту схему поменьше трогать, и во-вторых когда придёт время писать импорт из старой версии, можно было бы просто сравнивать старую схему с новой. Это marshmallow или pydantic.

Но может, лучше всё-таки не лезть в такую бутылку? Может, хотя бы не пихать в «результаты вычислений» произвольные питоньи объекты, чтобы потом с ними не долбаться как в аду?

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от PeleWin

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

Если сделать кривую/неудобную структуру то потом придется с ней очень долго мучаться, этот как раз то место где нельзя экономить на проектировании.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

То есть ты собираешься импортировать старые данные после того, как код был существенно изменен

Нет конечно, не настолько старые. Будет примерно как с pickle - есть юзерские типы но они уже устоялись. У нас очень четкое разделение на код имеющий статус библиотеки (прибито гвоздями наглухо) и то что быстро меняется. Тот код который поменялся, если на него данные не удалось накатить - ну умерла так умерла.

Если речь о накатывании всей структуры на тот код который эту структуру породил - вообще то для каждого расчета есть архив с иcходниками, можно поднять оттуда если очень надо;-)

AntonI ★★★★★
() автор топика

хочется уйти на json. Кроме того pickle все равно не умеет хранить комментарии

JSON тоже не умеет. Кроме того, я слышал, ты любишь отступы, так что YAML должен зайти.

Но я бы, конечно, рекомендовал EDN %)

Nervous ★★★★★
()
Ответ на: комментарий от Nervous

JSON тоже не умеет.

Тоже умеет, см. выше. Причём уже достаточно давно.

Ja-Ja-Hey-Ho ★★★★★
()

Что то не понимаю, если это сериализация, то откуда там комментарии возьмутся если компилятор/интерпретатор же про них не знает? Если это десериализация, то что мешает просто хранить .py-файлы?

thunar ★★★★★
()
Ответ на: комментарий от Ja-Ja-Hey-Ho

JSON5 – петушиная фигня.

JSON – данные для машин и от машин. Там комментарии есть изначально. Хранятся они как строка, выбранная конечным пользователем для этого.

{
    "data": 2,
    "comment": "Два"
}

И нет никакой нужды усложнять парсер.

thegoldone ★★
()

типизированных данных

json schema позволит организовать валидацию и типы

с комментариями в json

json5 поддерживает c-style комментарии

aol ★★★★★
()
Последнее исправление: aol (всего исправлений: 1)
Ответ на: комментарий от AntonI

Хранение результатов расчетов.

Есть куча вариантов. Если данных много - JSON это один из плохих вариантов.

JSON не поддерживает свободную запись в конец файла, только полную перезапись (ну без доп приседаний).

Так что если данных много, то смотреть нужно на JSONL, CSV. Еще есть HDF5 который как раз для хранения данных сделали.

Если нужно прямо чтобы в JSON, то я бы разделил JSON на два куска. Аннотацию со словарем типов, где по ключу будет описание типа и данные, где тип представлен просто именем будет. Так меньше места потратится. Как вариант - можно разделить на два файла данные и аннотации, но тогда продолбать что-то из них легче конечно будет.

Если же данных мало (мегабайты), то пофиг вообще как делать.

Norgat ★★★★★
()
Ответ на: комментарий от Ja-Ja-Hey-Ho

JSON5 … в Ruby … поддерживается

Ненужно поддерживается в ненужно, спешите видеть.

Nervous ★★★★★
()
Ответ на: комментарий от thunar

Целая тема была по этому поводу, и внезапно выяснилось что хоба — Рефлексия в плюсах - обойти все поля структуры в рантайм? (комментарий)

что мешает просто хранить .py-файлы?

Ну это как то чересчур… хотя м.б. и вариант, как наш ответ JSON-у;-)

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Ja-Ja-Hey-Ho

@aol че то я пока не пойму с этим json5… py3 из коробки его не умеет похоже (ну стандартный import json, или я сходу не нашел как).

Вариантов то много, но то кто то из гуру сказал что комментарии ненужны, какой то разброд и шатание…

Вот @thunar говорит не мучайся и просто сохраняй .py, мб он и прав.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Norgat

Если данных много - JSON это один из плохих вариантов.

JSON привлекает своей стабильностью, общеупотребимостью и читабельностью. А то будет как с pickle - выяснится через 20 лет что формат deprecated и вообще ушел ХЗ куда.

JSON не поддерживает свободную запись в конец файла, только полную перезапись (ну без доп приседаний).

В данном случае это не требуется, речь идет о сравнительно небольших (4K+/-) файлах с ключевыми параметрами. Большие объемы хранятся в отдельных бинарных файлах в совсем другом виде.

Если же данных мало (мегабайты), то пофиг вообще как делать.

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

Еще момент - таких файликов будет много. Для ускорения поиска я в piсkle строил общий кэш одним файлом.

Мб и правда json не лучший вариант…

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Ja-Ja-Hey-Ho

Вот прям щас я на ето все смотрю… смотрю… и хочу сделать свой формат под конкретно эту задачу. Что бы было и быстро и читабельно и не зависеть от чужих хотелок;-)

Взять свой стандартный конфиг который просто как табуретка

a 1      # размер баскетбольной площадки
b 2.5
c 1 2 3  # куда кидать мячик

и чуть доработать напильником - добавить возможность вложенности и опциональное аннотирование типов.

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

Ну все входные данные для задач я так и храню — в .py-файлах. Вот, например. При старте кода, собираю готовый объект из таких пресетов и засылаю в библиотеку. Для выходных данных чуть расширил формат .npz, не ломая с ним совместимость (что впрочем не мешает его и для входных данных использовать).

thunar ★★★★★
()
Последнее исправление: thunar (всего исправлений: 4)
Ответ на: комментарий от thunar

как бы наоборот

деды не зря придумали.

маршалинг демаршалинг в обьекты/модели по схеме - это прям базовый функционал любой либы работы с xml

не говоря уже про потоковый парсинг и обработку через xslt

до сих пор ничего лучше не придумано для описания бизнес агрегатов, например.

клоунский опенапи и десятой части функционала soap/xml не умеет

guyvernk
()
Последнее исправление: guyvernk (всего исправлений: 2)
Ответ на: комментарий от AntonI

Ну, будем честны, задача у тебя в ОП сформулирована довольно всрато - вот все и гадают, чо ж те надо..

aol ★★★★★
()
Ответ на: комментарий от AntonI

В данном случае это не требуется, речь идет о сравнительно небольших (4K+/-) файлах с ключевыми параметрами.

Тогда не парься и возьми JSON. Работать просто, оверхед низкий, сменить формат - напишешь промпт для GPT и тебе выдаст готовый скрипт переформатирования.

Norgat ★★★★★
()
Ответ на: комментарий от aol

Как мог так сформулировал… thunar вот понял;-)

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Norgat

Дык его придется как то дорабатывать напильником. А тогда уж можно и свой формат брать, JSON то прям скажем не идеален

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

вообще то для каждого расчета есть архив с иcходниками, можно поднять оттуда если очень надо;-)

Ну и в этих же исходниках есть комменты. Если дело дойдет до того, что придётся глазами вычитывать комменты в сохраненных результатах, то может тогда и в исходники залезть не будет такой уж большой проблемой?

Будет примерно как с pickle

Ну а с самим pickle у тебя на практике есть вообще какие-нибудь проблемы? Ты написал про "чехарда с форматами и невнятные перспективы", но это ведь не в практической плоскости лежит.

Manhunt ★★★★★
()
Ответ на: комментарий от AntonI

JSON гибкий, парсеры его у тебя есть из коробки везде. Зачем тратить время на свой велосипед? Если бы ты просто сел и начал пилить на JSON - уже сделал бы пока тут обсуждаем все это)

Norgat ★★★★★
()

jsonpickle

E ★★★
()
Ответ на: комментарий от Manhunt

может тогда и в исходники залезть не будет такой уж большой проблемой?

Что бы достать коммент из исходника (который уже поменялся) надо распаковать и собрать старый исходник. С учетом того что расчетов в базе неск тысяч дороговато будет;-)

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

Ну а с самим pickle у тебя на практике есть вообще какие-нибудь проблемы?

Переходил давеча с py2 на py3 и наелся полной ложкой. В итоге все получилось (удалось читать новым кодом старые файлы и писать новым кодом файлы которые понимает старый код), но не без плясок с бубном, и прям скажем старые и новые записи отличаются.

Когда я выбирал pickle 20 лет назад, это казалось хорошей идеей - я тогда только-только узнал про сериализацию, а тут оно все само из коробки. Сейчас я понимаю что выбор был прямо скажем не айс, особенно с учетом тендценций развития питона и постоянным сломом обратной совместимости. Поэтому и хочется сменить формат, но на что то такое что лет 30 проживет без необходимости туда лазить. Что бы написал и забыл а оно себе работает;-).

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Norgat

Что бы сделать надо понять что именно сделать;-)

Вот пока обсуждаем понимание потихоньку приходит…

AntonI ★★★★★
() автор топика
Ответ на: комментарий от thunar

Мысль интересная и действительно нет никаких ограничений. Что смущает:

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

  2. начал думать вот куда - такой файл руками написать/редактировать сложно. Сейчас потихоньку начала возникать потребность в конфигах (иногда это удобнее чем пускач на питоне, особенно при работе в коллективе), конфиги пишутся/редактируются руками. Вот не убить ли одним выстрелом двух зайцев - что бы и данные хранить, и как конфиг это юзать…

Одно из требований к конфигу - простота парсинга на плюсах. Потому что питоновская обертка для запуска у нас есть не всегда.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

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

Тут какая-то путаница в показаниях получается. То ты пишешь, что если старые данные не загрузились, то и хрен с ними. То ты пишешь, что даже если старые данные загрузились, спокойно ими пользоваться всё равно нельзя, а надо сидеть и глазами выспрашивать у системы обработки смысл параметров.

Тогда всё-таки надо отделить метаданные о расчетах (состав и неформальное описание смысла параметров) от собственно результатов расчетов (значения параметров). То есть отдельно хранить схему данных (+комменты к схеме), и отдельно сами данные. И вычитывать ты будешь не перемешанные с данными комменты, а будешь делать diff между схемами (актуальной, и той, которая сохранена вместе с данными), процесс вычитывания от этого вроде как должен значительно упроститься. При загрузке/выгрузке данных, они должны всегда и автоматически валидироваться на формальное соответствие схеме...

с учетом тендценций развития питона и постоянным сломом обратной совместимости

Для pickle же есть явное обещание обратной совместимости: "The pickle serialization format is guaranteed to be backwards icompatible across Python releases provided a compatible pickle protocol is chosen and pickling and unpickling code deals with Python 2 to Python 3 type differences if your data is crossing that unique breaking change language boundary."

Поэтому и хочется сменить формат, но на что то такое что лет 30 проживет без необходимости туда лазить. Что бы написал и забыл а оно себе работает;-)

Наоборот, из-за изменений в языке придётся время ото времени лазить в самодельный сериализатор и адаптировать его под новые реалии. А с готовыми библиотеками (и с pickle в частности) за тебя это делают другие люди, знай обновляйся..

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от lovesan

S-expressions делают ненужными ни JSON ни XML ни что-то подобное другое

Конечно, только с поправкой на то, что все реализации различаются в деталях и нет никакого стандарта. И как нужно это парсить на другом языке программирования, так оказывается что парсера или нет вообще, или есть, но на другой диалект.

maxcom ★★★★★
()
Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от AntonI

В результате попытки скрестить сериализацию объектов и конифги получается каша с противоречивыми требованиями. То есть ни конфигов адекватных не будет, ни сериализации адекватной не будет, а будет убогий и уродливый франкенштейн.

Для конфигов посмотри пристальнейшим образом на toml. Для него есть готовые либы и на питоне, и на плюсах, и на множестве других языков. И сделан он для людей.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

Тогда всё-таки надо отделить метаданные о расчетах (состав и неформальное описание смысла параметров) от собственно результатов расчетов (значения параметров).

Зачем? В обсуждаемом файле хранятся входные параметры расчета, ключевые результаты расчета (какое то относительно небольшой набор чисел), информация о расчете (версии исходников, какие то тэги, аргументы командной строки, время выполнения и пр) и хочется добавить описание параметров. Этот подход шлифовался два десятилетия. Разносить это по нескольким файлам не вижу смысла по множеству причин.

Этот файл может использоваться очень разными способами - от поиска по базе (и тогда исходники расчета не нужны) до перезапуска расчета с новыми исходниками (старые исходники ненужны, но параметры на новые исходники могут не накатится) и даже повтора расчета со старыми исходниками (вот тогда они нужны).

Для pickle же есть явное обещание обратной совместимости

Есть. Но я им уже не верю, после того с чем столкнулся при переходе 2to3. И даже сейчас, несмотря на их обещания, переход вышел крайне болезненным, в частности потому что часть данных под pickle у меня бинарные. Сейчас я понимаю что это была плохая идея и все очень хрупко, но раз уж планируется что то менять - то есть шанс сделать все по фен-шую. Ну или по мои нынешним представлениям о фен-шуе;-)

из-за изменений в языке придётся время ото времени лазить в самодельный сериализатор

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

AntonI ★★★★★
() автор топика
Ответ на: комментарий от Manhunt

Я знал что Вы это скажете;-)

В итоге будет две сущности вместо одной, мне не нравится.

AntonI ★★★★★
() автор топика
Ответ на: комментарий от thegoldone

JSON – данные для машин и от машин. Там комментарии есть изначально.

Машинам комментарии не нужны, при изменении json они их просто удалят, разработчикам легче записать новый файл, чем изменять существующий. Если конечно они не предусмотрели личные комменты.

dmitry237 ★★★★
()

Хорошим примером хранения результатов научных вычисления является HDF5. И представления построенные по верх него.

Забегая в перёд, вариант объединения всех атрибутов в одну стурктуру.

'a': {
  'value': 1,
  'dtype': 'f32',
  'attrs' : [
    'long_name': 'длина баскетбольной площадки',
    'units': 'm',
    'error': 0.15
  ]
}

HDF5 - нестолько формат, сколько библиотека для работы с этим форматом. Но эта библиотека позволяет работать с многомерными таблицами хранящимися на диске в MPI среде, т.е. даёт параллельную запись/чтение в файл на вычислительном кластере.

Формат скудный, группы, многомерные таблицы и атрибуты - всё что в нём есть. Не так и много утилит для работы с ним. Но своя ниша у него есть.

HDF5 + NeXus format

Поверх HDF5 есть NeXus format: https://www.nexusformat.org/ Его рекомендую полистать.

В рамках этого формата представления данных определяются не только дополнительные атрибуты (long_name, units, …) но и желательное вариант их отображения.

Пример online просмотр файла в формате hdf5 + NeXus: https://myhdf5.hdfgroup.org/view?url=https%3A%2F%2Fzenodo.org%2Frecord%2F6497438%2Ffiles%2Fxrr_dataset.h5%3Fdownload%3D1

Рекомендую найти разные типы данных (скалярные, одно- и двухмерные). Попереключать Display/Inspect, что бы рассмотреть атрибуты.

HDF5

Пример того, как данные организует голый HDF5

import h5py

f = h5py.File('test.hdf5', 'w')

gr = f.create_group('compute_results')

a = gr.create_dataset('a', (1,), dtype="f")
a[0] = 1
a.attrs['long_name'] = 'размер баскетбольной площадки'
a.attrs['units'] = '100 m^2'

gr['b'] = [2.5]

gr['c'] = [1,2,3]
gr['c'].attrs['comment'] = 'куда кидать мячик'

f.close()

Результат утилиты h5dump:

HDF5 "test.hdf5" {
GROUP "/" {
   GROUP "compute_results" {
      DATASET "a" {
         DATATYPE  H5T_IEEE_F32LE
         DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         DATA {
         (0): 1
         }
         ATTRIBUTE "long_name" {
            DATATYPE  H5T_STRING {
               STRSIZE H5T_VARIABLE;
               STRPAD H5T_STR_NULLTERM;
               CSET H5T_CSET_UTF8;
               CTYPE H5T_C_S1;
            }
            DATASPACE  SCALAR
            DATA {
            (0): "\37777777721\37777777600\37777777720\37777777660\37777777720\37777777667\37777777720\37777777674\37777777720\37777777665\37777777721\37777777600 \37777777720\37777777661\37777777720\37777777660\37777777721\37777777601\37777777720\37777777672\37777777720\37777777665\37777777721\37777777602\37777777720\37777777661\37777777720\37777777676\37777777720\37777777673\37777777721\37777777614\37777777720\37777777675\37777777720\37777777676\37777777720\37777777671 \37777777720\37777777677\37777777720\37777777673\37777777720\37777777676\37777777721\37777777611\37777777720\37777777660\37777777720\37777777664\37777777720\37777777672\37777777720\37777777670"
            }
         }
         ATTRIBUTE "units" {
            DATATYPE  H5T_STRING {
               STRSIZE H5T_VARIABLE;
               STRPAD H5T_STR_NULLTERM;
               CSET H5T_CSET_UTF8;
               CTYPE H5T_C_S1;
            }
            DATASPACE  SCALAR
            DATA {
            (0): "100 m^2"
            }
         }
      }
      DATASET "b" {
         DATATYPE  H5T_IEEE_F64LE
         DATASPACE  SIMPLE { ( 1 ) / ( 1 ) }
         DATA {
         (0): 2.5
         }
      }
      DATASET "c" {
         DATATYPE  H5T_STD_I64LE
         DATASPACE  SIMPLE { ( 3 ) / ( 3 ) }
         DATA {
         (0): 1, 2, 3
         }
         ATTRIBUTE "comment" {
            DATATYPE  H5T_STRING {
               STRSIZE H5T_VARIABLE;
               STRPAD H5T_STR_NULLTERM;
               CSET H5T_CSET_UTF8;
               CTYPE H5T_C_S1;
            }
            DATASPACE  SCALAR
            DATA {
            (0): "\37777777720\37777777672\37777777721\37777777603\37777777720\37777777664\37777777720\37777777660 \37777777720\37777777672\37777777720\37777777670\37777777720\37777777664\37777777720\37777777660\37777777721\37777777602\37777777721\37777777614 \37777777720\37777777674\37777777721\37777777617\37777777721\37777777607\37777777720\37777777670\37777777720\37777777672"
            }
         }
      }
   }
}
}

P.S.

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

Но вопросы организации хранения научных данных с ним и поверх него решались не один раз. Кроме значения, типа данных, комментария есть ещё единицы измерения, ошибка измерения/вычисления, параметры для отображения, время измерения, и т.д. и т.п.

P.S.S.

Json и XML - человеко-читаемые форматы. Но для редактирования они так себе. Выбирая их, можно смело забивать на многословность. Это форматы для общения программ, за которым могут наблюдать люди.

Хочешь что-то ориентированное на редактирование человеком? Посмотри в сторону форматов ориентированных на конфигурационные файлы. Аля libconfig или toml

Ну или придумай что-то, что хорошо подходит к твоим задачам.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

Спасибо большое, интересно!

HDF5 у нас не зашел (хотя когда то его смотрели) потому что мы это как то средствами ФС делаем, показалось что так быстрее и проще. На кластерах обычно СХД развернуты, хотя всегда предпочитаем работать с локальными дисками.

Ну и вьюверы традиционно свои потому что объемы данных очень большие и традиционные вьюверы их обычно не тянут.

libconfig или toml

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

Ну или придумай что-то, что хорошо подходит к твоим задачам.

Вот че то я боюсь этим все и закончится;-(

AntonI ★★★★★
() автор топика
Ответ на: комментарий от AntonI

Можно же комбинировать toml со своими правилами именования:

[input_data]

a__long_name = "размер баскетбольной площадки"
a = 1
a__units = "m"
     
b = 2.5
b__units = "s"

# куда кидать мячик
c = [1, 2, 3]  

Так атрибуты данных выглядят не очень страшно.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

Да, это понятно. Но как только речь зашла про свое начинает хотеться и такого

a = 1
b = 2.5
c = [a, a+b, sin(pi*a)]

Вот где весь ужос то…

Хотя это конечно уже можно сделать поверх toml

AntonI ★★★★★
() автор топика
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

скажем а не писать ли в человекоредактируемой части конфига алгебраические выражения при задании параметров

Это уже попахивает DSL (Domain-Specific Language), а этого лучше избегать. Для таких вещей уже есть python, для которого с помощью pybind11 не сложно описать одну функцию с конфигом на входе.

AlexVR ★★★★★
()
Последнее исправление: AlexVR (всего исправлений: 2)
Ответ на: комментарий от AlexVR

Конечно это всегда делалось в рамка питоновского пускача. Но все эти границы между пускачом/конфигом/метаинформацией о расчете несколько размыты…

AntonI ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.