Стащил

[eddy_em]

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

Кому интересно — попробуйте потестировать.

Comments

[masterspammer.livejournal.com]

Тоже как-то форкал для работы ini-парсер (на питоне).

Хотелось следующего:

1. метаинформация - значение хранилось в такой-то строке (чтоб ругаться - у вас, мол ошибка в такой-то строке INI-файла)
2. поиск ключей, к которым не было обращения (для отладки)
3. при интерполяции и доступе по ключу подсовывание метаинформации - вот такая переменная взята оттуда-то и в итоге __почти__ stacktrace (из какой строки включили другой файл, откуда взялся ключ, для которого нет значения и т.д.

В итоге пришлось дописывать очень многое :-(

[eddy-em.livejournal.com]

Ну, мне пока нужно немногое — хранить кое-какие вещи в ini-файлах, чтобы не делать alias'ов с толпой ключей, которые указываются постоянно.
Кроме того, ini-файлы позволят уменьшить количество ключей (скажем, в apogee_control список ключей уже с трудом в 1 экран вмещается, конечно, до mplayer/mencoder это далеко, но как-то неуютно). В sextractor, например, проблему 100500 ключей решили упоминанием всего нужного в конфигурационных файлах.

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

[masterspammer.livejournal.com]

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

[eddy-em.livejournal.com]

Это да. Попытка запилить все в одну кучу приводит к созданию монстров-уродцев вроде OpenCV.