Главная проблема Cython [и главное препятствие на пути его широкого распространения] с моей т.з. — аннотации типов в нём задаются по-своему, отлично от Python Type Hints (доступных начиная с Python 3.5).
А также, насколько я понял, нет достаточно удобного отладчика для Cython (кроме DDD ничего не нашёл). [Для 11l это не такая острая проблема, так как можно отлаживать Python-код перед отдачей его транспайлеру Python → 11l, а с Cython так не получится, так как код на нём написанный не совместим с Python.]
Да, только они называются типами (как в Go).
Коротенький пример есть в документации.
По умолчанию типы в 11l являются "типами-значениями" [а не "типами-ссылками"] и работают как структуры (struct) в C или C++.
В случае, когда тип Type ссылается сам на себя, Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
В случае, когда тип Type содержит виртуальные функции, Type заменяется на std::unique_ptr<Type> (пример).
А можете привести самые удачные?
Просто я толковых проектов не нашёл (помимо упомянутых в статье Nuitka и Shed Skin, я попробовал py14, Pythran и Py2C).
Очень бы хотелось увидеть пример хорошего использования декораторов.
Вы не могли бы дать ссылочку на код [если он в open source, разумеется]?
Буду крайне признателен.
Ну, начиналось всё с преобразователя 11l → C++. О компиляции/ускорении кода на Python я тогда вообще не думал.
И лишь спустя полгода была начата работа над Python → 11l.
Почему не над Python → C++?
Ну, во-первых, 11l гораздо ближе к Python, чем C++ к Python.
Во-вторых, не буду скрывать, проект Python → 11l задумывался с целью популяризации языка 11l.
С моей точки зрения они только запутывают [на основе опыта перевода этого кода с декоратором @method — код без декоратора получился более понятным].
А "стандартные" декораторы (@property, @classmethod, @staticmethod), имхо, лучше поддерживать в синтаксисе языка программирования.
Впрочем, я поторопился с ответом. И если получится найти несложный способ реализации декораторов, то можно и добавить их поддержку.
На данном этапе, увы, нет.
В этом проекте слишком много чего импортируется и слишком много возможностей Python используется.
[[[А декораторы поддерживать вообще не планируется.]]]
Да, я уже видел вашу статью. Но, если честно, не очень впечатлили возможности этого формата (нет комменатриев и массивов [а это и правда удобно, когда формат данных гладко ложится на структуры данных используемого языка программирования (или вы при решении задач никогда не пользовались массивами?), и в этом я вижу основную причину такой популярности JSON]).
У вас в статье заявлена реализация на TypeScript/JavaScript, но я её не нашёл.
И с примерами вы "читерите":
Сразу мне стало интересно как этот пример, использующий массив users, ляжет на ваш формат, который массивы не поддерживает.
В sample.tree видим:
user
name \John
age 30
user
name \John
age 30
Ещё интереснее. Как получили строки user? Неужели конвертер настолько умный, что догадался откусить признак множественного числа — последнюю букву 's' в слове users?
Оказалось, ничего подобного.
Вот результат честной конвертации:
Ну да. Точка является обозначением начала нового подобъекта в массиве (аналогично в YAML используется "-": можете сами попробовать конвертер JSON в YAML).
А какую бы вы запись предпочли?
Вы привели невалидный JSON. Вообще, я уже упоминал в статье — можно попробовать cконвертировать JSON в новый формат прямо в браузере на веб-странице проекта.
При правке различных конфигов периодически забываю ставить запятые. А также не нравится обязательное заключение параметров и их значения в кавычки.
В этот формат комментарии тоже не завезли?
Хотя явной поддержки комментариев в данной реализации нет, но особенность этого формата такова, что строка:
//font_face = Fira Code
не является ошибкой, а является по смыслу аналогичной вот такой строки в JSON:
"//font_face": "Fira Code"
При таком подходе "комментарии" сохраняются автоматически, а не удаляются как происходит к примеру в JSON-парсерах с поддержкой комментариев.
И все же?
Не понял ваш вопрос. Русская версия поддерживается и всё, в чём она заключается, это поддержка русской буквы В в 0В и 1В, а также русская Н в значении null/None.
Или как вы предлагаете не "увеличивать кол-во C++-кода"? Ведь фигурные скобки в этом примере необходимы и являются требованием языка C++.
Почему не могу? 11l позволяет выделять блоки как отступом так и/или фигурными скобками.
А также, насколько я понял, нет достаточно удобного отладчика для Cython (кроме DDD ничего не нашёл). [Для 11l это не такая острая проблема, так как можно отлаживать Python-код перед отдачей его транспайлеру Python → 11l, а с Cython так не получится, так как код на нём написанный не совместим с Python.]
Коротенький пример есть в документации.
По умолчанию типы в 11l являются "типами-значениями" [а не "типами-ссылками"] и работают как структуры (struct) в C или C++.
В случае, когда тип Type ссылается сам на себя, Type заменяется на SharedPtr<Type> (см. первый пример отсюда).
В случае, когда тип Type содержит виртуальные функции, Type заменяется на std::unique_ptr<Type> (пример).
Просто я толковых проектов не нашёл (помимо упомянутых в статье Nuitka и Shed Skin, я попробовал py14, Pythran и Py2C).
Вы не могли бы дать ссылочку на код [если он в open source, разумеется]?
Буду крайне признателен.
И лишь спустя полгода была начата работа над Python → 11l.
Почему не над Python → C++?
Ну, во-первых, 11l гораздо ближе к Python, чем C++ к Python.
Во-вторых, не буду скрывать, проект Python → 11l задумывался с целью популяризации языка 11l.
@method— код без декоратора получился более понятным].А "стандартные" декораторы (@property, @classmethod, @staticmethod), имхо, лучше поддерживать в синтаксисе языка программирования.
Впрочем, я поторопился с ответом. И если получится найти несложный способ реализации декораторов, то можно и добавить их поддержку.
В этом проекте слишком много чего импортируется и слишком много возможностей Python используется.
[[[А декораторы поддерживать вообще не планируется.]]]
Но это не снимает вопрос о том, где смотреть код функции img.load(). [А, уже ответили выше.]
(я думал, что правильно писать так:
pix[X][Y]илиpix[Y][X])Просто если
pix = [[1, 2], [3, 4]], тоpix[0, 1]у меня выдаёт ошибку ‘‘list indices must be integers or slices, not tuple’’.У вас в статье заявлена реализация на TypeScript/JavaScript, но я её не нашёл.
И с примерами вы "читерите":
Берём sample.json:
Сразу мне стало интересно как этот пример, использующий массив users, ляжет на ваш формат, который массивы не поддерживает.
В sample.tree видим:
Ещё интереснее. Как получили строки
user? Неужели конвертер настолько умный, что догадался откусить признак множественного числа — последнюю букву 's' в слове users?Оказалось, ничего подобного.
Вот результат честной конвертации:
И вы поставили человекопонятность этому формату пятёрку?
В 0В и 1В допускается использовать как английскую, так и русскую В.
Ну да. Точка является обозначением начала нового подобъекта в массиве (аналогично в YAML используется "
-": можете сами попробовать конвертер JSON в YAML).А какую бы вы запись предпочли?
Вы привели невалидный JSON. Вообще, я уже упоминал в статье — можно попробовать cконвертировать JSON в новый формат прямо в браузере на веб-странице проекта.
Хотя явной поддержки комментариев в данной реализации нет, но особенность этого формата такова, что строка:
не является ошибкой, а является по смыслу аналогичной вот такой строки в JSON:
При таком подходе "комментарии" сохраняются автоматически, а не удаляются как происходит к примеру в JSON-парсерах с поддержкой комментариев.
Не понял ваш вопрос. Русская версия поддерживается и всё, в чём она заключается, это поддержка русской буквы
Вв0Ви1В, а также русскаяНв значенииnull/None.