Кто говорил, что в JSON невозможно добавлять комментарии?

Но ведь можно взять какой-нибудь https://json5.org/ или YAML, или любой другой современный формат. А таких костылей в сам JSON можно сколько угодно напридумать (даже решающих проблему повторяющихся ключей), смысла в них мало, т.к. ни один из них не станет стандартом.

Мам, мам, можно мне YAML с комментариями?

JSON: У нас есть комментарии дома

Дома:

Мож хватит а?! Ща жсб-и набегут, скажут что это новый стандарт, а потом е-сь с ним. НЕ НУЖНО ЭТО. ОНО Р А Б О Т А Е Т

Это старый стандарт и всегда работало. Вот уже 20 лет, как.

ОП просто пришел рассказать, что никогда не знал как устроен JSON. Впрочем, как и ты.

jsonc.

Апхах, YAML! Вы вообще читали, какой там пиздец с парсингом? Каждая распространенная библиотека парсит по своему, стандарт это никак не покрывает, сам стандарт по размеру как роман Дюма, а у ямла еще и версионирование формата, где ломалась совместимость

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

YAML обычно для конфигов используют, а не для хранения данных.

Хотя если в данных зачем-то понадобились комментарии, то это, скорее всего, и есть какой-то конфиг.

Это не комментарии, это слёзы

Вроде там тривиально всё, как его можно по-разному парсить, да ещё и ломать что-то? Разве что про экранирование символов в строках что-нить. Писал к нему парсер, про наличие стандарта даже не знал.

YAML не единственная альтернатива. Если тебя пугает(вполне обоснованно) его сложность, есть toml

Если завязываться на особенности парсера, то лучше просто использовать парсер умеющий комментарии (например, JSON5).

А у твоего варианта есть проблема с комментариями для элементов массивов.

Господь вам дал божественный XML, с блекджеком, схемой и комментариями, но вы всё равно едите говно с костылями (json), с отступами (yaml) и прочую дичь.

Я всегда думал, что на ближайшем yaml пишут, проверяя, что получается в результате и подгоняют под результат.

У XML проблема - теги. Идеально - писать на yaml с целью конвертировать в XML imho

А в чем проблема тегов?

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

но если этот JSON не пишется машиной, а только читается

На том же питоне вполне себе можно читать и писать json с повторяющимися ключами.

Я за ними не вижу данных.

УМВР.

коментил так же, только через массивы

Все уже давно на yaml перешли.

Скажем дружно: Json - не нужно!

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

В нормальном редакторе отступы не ахтунг.

Я в итоге для HTML на pug (типа haml для всех) перешёл.

Даже jinja2 пишу на pug.

https://habr.com/ru/post/710414/

Там много примеров. Например:

port_mapping:
  - 22:22
  - 80:80
  - 443:443

{"port_mapping": [1342, "80:80", "443:443"]}

Ой, а что здесь произошло? Оказывается, числа от 0 до 59, разделённые двоеточиями — это шестидесятеричные (по основанию 60) числовые литералы. Эта загадочная фича присутствовала в YAML 1.1, но была незаметно удалена из YAML 1.2, поэтому в зависимости от версии, которую использует парсер, элемент списка спарсится как 1342 или как «22:22». Формату YAML 1.2 уже больше десяти лет, но если вы предположите, что он широко поддерживается, то ошибётесь: последняя версия libyaml на момент написания (которая, среди прочего, используется и в PyYAML) реализует YAML 1.1 и парсит 22:22 как 1342.

Мда, неожиданно. Ну, значит yaml из стандартов не нужен, а нужен его очень упрощённый вид, не содержащий ничего неожиданного. В частности, типы в нём лишние, пусть всё будет строками (всё равно его кроме как для конфигов не используют), которые уже приложение по своему усмотрению распарсит. Всякие теги/якоря/ссылки (узнал из статьи по ссылке) тоже в нём не нужны.

Ямлы, жсоны. Даешь конфиги прямо в markdown! Например, в блоках кода. Типа literate programming, только literate configuring.

Я и название уже придумал — yadown.

Значения ключей «#» — комментарии.

Где-то встречал, что для комментариев использовали ключ «comment», без повторений. Читалось вполне нормально.

Если речь о конфигах, то, в качестве альтернативы json-у, есть смысл посмотреть на toml

Если парсить средствами Питона, можно добавлять повторяющиеся ключи

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

Пока ты посчитаешь, сколько в этом тысяч страниц спеков, мы уже доели.

Доели говно, попутно схлопотав пару инцидентов на проде из-за корявых отступов в конфиге?

Завидуешь наличию прода? Читай дальше, будет в 2030 и на твоей улице праздник.

Ну я хотя бы могу аппаратно ускорять процессинг XML с помощью IBM Datapower, а как ускоряешь перекладывание жисонов ты?

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

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

Да YAML просто создан быть идеальным инструментов выстрела в ногу.

А если парсить джаваскриптовским eval

Выше объяснили, почему их убрали.

А без комментариев можно и питоновским eval.

На том же питоне вполне себе можно читать и писать json с повторяющимися ключами.

И как это сделать, сохранив все повторения?

А у твоего варианта есть проблема с комментариями для элементов массивов.

В смысле, нельзя вставлять комментарии между элементами массива, к которым доступ по номеру? Да, проблема. Хотя не могу представить случая, когда нельзя было бы вынести комментарий за пределы массива. Если это именно конфиг.

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

Что мешает присваивать несуществующие имена выключаемым параметрам?

Хотя с многострочными неудобно, да.

Если совсем hacky и по-быстрому, то вот так:

import json

class Pairs(dict):
    def __init__(self, pairs):
        super().__init__(pairs)
        self.pairs = pairs

    def __repr__(self):
        return f'Pairs({self.pairs!r})'

    def items(self):
        return self.pairs

j = '{"key1": "a", "key2": "b", "key1": "c"}'
print('Original json:', j)

data = json.loads(j, object_pairs_hook=Pairs)
print('Parsed data:', data)

j1 = json.dumps(data, indent=4)
print('Redumped json:', j1)

Original json: {"key1": "a", "key2": "b", "key1": "c"}
Parsed data: Pairs([('key1', 'a'), ('key2', 'b'), ('key1', 'c')])
Redumped json: {
    "key1": "a",
    "key2": "b",
    "key1": "c"
}

Это даже если забыть про то что он пытается внешние модули выполнить что remote execution делает.

А я — вижу. И Сосиска видит.

Другое дело, что XML просто надо уметь готовить. Когда составляешь конкретную схему, очень легко впасть в грех универсальности и нагородить плохой нечитаемый XML. Вот например, ui-файлы в Qt — пример плохого XML, к сожалению. Сделали бы его хорошим — никакой QML бы не понадобился. Возможно, тебе попадались именно плохие XML.

Ну вот даже настройки mediatomb/gerbera - боль.

Другое дело, что XML просто надо уметь готовить.

С ним нужно и уметь работать.

Например разработал API, которое умеет создать метаданные для
любой сложности xml (и обобщенные алгоритмы, умеющие
проанализировать набор XML и создать метаданные, учитывающие все нюансы).

Алгоритмы оттестированы на форматах данных Microsoft Office.

В чем профит?

Одной строчкой кода xml любой сложности загружается в struct/class.
При этом все атрибуты и значения программно конвертируются в нативный формат.

Удобно?
И что ни кто не знал, что такое API можно и нужно разработать?
Знали!
В чем проблема?

Ждем халяву.

Разработка алгоритмов для работы с объектами - моя повседневная работа.

Разработано всего лишь где-то сэм, восэм процентов от планируемого.

Надеюсь в этом году много полезных и вкусных плюшек испечь.

Опубликую?
Конечно, но пока явно рановато.

API поддерживает создание и работу с объектами любой сложности.

------------------------------------
Что касаемо JSON и XML, то у каждого из них имеется своя ниша в которой их приемлемо использовать.

API поддерживает создание и работу с объектами любой сложности.

Что-то рекурсивное? Тоже писал подобное, для разбора объектов JS.

В чем проблема?

Я бы сказал в том, что

Руки всего две

Что-то рекурсивное? Тоже писал подобное, для разбора объектов JS.

Метаданные используются для задания архитектуры объекта.
Объекты могут содержать базовые типы данных и объекты.

Я бы сказал в том, что
Руки всего две

А если они еще и ленивые в добавок, то ...