Не понравился встроенный http.server, дико ограниченный, даже range request-ы не умеет. По-моему самый убогий хттп сервер из всех, которые я когда-либо видел. Было бы неплохо привести его в более адекватное состояние, раз уж в стандартную библиотеку решили его засунуть.
Здравствуйте, Ватакуси, Вы писали:
В>3.11, скажем?
Понятия не имею, что там в питоне. Но я бы хотел (и не только для питона) получить некое жёстко ограниченное подмножество языка, чтобы его можно было компилировать в JS и не получать при этом BLOB размером в 2 мегабайта.
Чтобы вот в исходнике написать use restricted v1 и после этого компилятор не разрешал бы использовать ничего за пределами подмножества в этом файле. Из обычного питона можно пользоваться сущностями из этого файла, а из файла нельзя обращаться к обычному питону.
В>>3.11, скажем?
С>Понятия не имею, что там в питоне. Но я бы хотел (и не только для питона) получить некое жёстко ограниченное подмножество языка, чтобы его можно было компилировать в JS и не получать при этом BLOB размером в 2 мегабайта.
С>Чтобы вот в исходнике написать use restricted v1 и после этого компилятор не разрешал бы использовать ничего за пределами подмножества в этом файле. Из обычного питона можно пользоваться сущностями из этого файла, а из файла нельзя обращаться к обычному питону.
Может сразу взять JS?
Здравствуйте, Ватакуси, Вы писали:
С>>Чтобы вот в исходнике написать use restricted v1 и после этого компилятор не разрешал бы использовать ничего за пределами подмножества в этом файле. Из обычного питона можно пользоваться сущностями из этого файла, а из файла нельзя обращаться к обычному питону. В>Может сразу взять JS?
Нет, это невозможно и не нужно. Я имею в виду очень простую вещь — использование одного и того же кода для бэка и фронта, но без порождения монстриков вроде Google Web Toolkit или даже свежего Blazor.
Вот есть у нас сущность, большая и развесистая, у неё сложная логика валидации. Валидатор идёт по полям и создаёт сообщения об ошибках в списке. Почему до сих пор в 2021 году нужно либо писать подобное два раза на разных языках, либо выдумывать невероятно кривую декларативную валидацию (ещё одну, 100500ую по счёту), либо тащить JS на бэк.
С>Вот есть у нас сущность, большая и развесистая, у неё сложная логика валидации. Валидатор идёт по полям и создаёт сообщения об ошибках в списке. Почему до сих пор в 2021 году нужно либо писать подобное два раза на разных языках, либо выдумывать невероятно кривую декларативную валидацию (ещё одну, 100500ую по счёту), либо тащить JS на бэк.
Почему нельзя это делать через REST?
Прислал запрос, там проверили — ответили — ты показал пользователю.
В>>Может сразу взять JS?
С>Нет, это невозможно и не нужно. С>Я имею в виду очень простую вещь — использование одного и того же кода для бэка и фронта, но без порождения монстриков вроде Google Web Toolkit или даже свежего Blazor.
Смотри: есть нода, но тебе не нравится. Есть генераторы js для миллиона языков, но ты пишешь, что они все от 2х мб генерят. У меня сильное подозрение, что у тебя там какие-то ограничения (не факт, что на самом деле необходимые), которые не были озвучены.
Здравствуйте, Слава, Вы писали:
С> Вот есть у нас сущность, большая и развесистая, у неё сложная логика валидации. Валидатор идёт по полям и создаёт сообщения об ошибках в списке. Почему до сих пор в 2021 году нужно либо писать подобное два раза на разных языках, либо выдумывать невероятно кривую декларативную валидацию (ещё одну, 100500ую по счёту)
Это работает только на простых демках. Чуть шаг в сторону, и вдруг это создаёт проблем больше, чем решает. Скажем, валидатор может выглядеть по-разному. Можно тупо скрипт запилить, можно <input maxlength> прописать, можно указать, что <input type=email> (чтобы на мобилах отобразилась подходящая клавиатура), можно нестандартно маппить контролы на поля (например, юзеру позволять ставить пробелы в номере кредитки, но убирать их для сервера), можно как-то кастомно форматировать значения при вводе, можно рисовать кастомные контролы и т.п. А некоторые валидации в принципе не работают на клиенте.
Поэтому твоя хотелка — это попытка решить тривиальную проблему сложным универсальным способом.
Нафиг не надо.
Здравствуйте, Слава, Вы писали:
С>Нет, это невозможно и не нужно. Я имею в виду очень простую вещь — использование одного и того же кода для бэка и фронта, но без порождения монстриков вроде Google Web Toolkit или даже свежего Blazor.
Здравствуйте, novitk, Вы писали:
N>Язык без батареек никому нужен, а большинство батареек у питона на C/C++. Варианты решения твоей проблемы: N>а) Пишем валидатор на JS, на питоне подключаем через https://github.com/sqreen/PyMiniRacer или что-то похожее N>б) https://github.com/pyodide/pyodide, но тяжелая артиллерия
Вы, как и прочие участники треда, не понимаете задачу. А она достаточно частая и не требует "батареек". Допустим, у нас есть большая форма с 30 полями, и они между собой разумеется связаны. Там что-то рассчитывается, пересчитывается и проверяется. Это задача чисто алгоритмическая, и не требует ни рефлексии, ни наличия HashСode у каждого возможного типа, ни локализации строк, ни локалей для decimal'ов, ни горутин с async/await. Это может быть написано на паскале, на том самом, древнем процедурном.
Ну и чего ради надо писать обвес вокруг валидации и перерасчёта два раза? На бэке и на фронте. А ведь писать-то придётся, причём со страданиями, потому что подобные формы, например ипотечные или страховые, пишутся по указаниям специалистов по предметной области.
Есть язык Ada, а к нему ограниченное подмножество SPARK. Сама по себе Ада большая и может многое, вплоть до обработки прерываний и встроенной многозадачности в разных вида, а SPARK всего этого не умеет, зато программы на нём можно верифицировать.
Подобную чисто расчётную (без IO) часть будет легко протестировать и затем использовать во всех нужных местах.
Здравствуйте, Слава, Вы писали:
С>Вы, как и прочие участники треда, не понимаете задачу. А она достаточно частая и не требует "батареек".
Задача валидации полей не требующая даже регекспов вряд ли можно назвать частой. Впрочем я описал тебе возможности ее решить на едином языке прямо сейчас без созданий очень дорогой фичи с подмножеством языка.
Здравствуйте, novitk, Вы писали:
С>>Вы, как и прочие участники треда, не понимаете задачу. А она достаточно частая и не требует "батареек". N>Задача валидации полей не требующая даже регекспов вряд ли можно назвать частой. Впрочем я описал тебе возможности ее решить на едином языке прямо сейчас без созданий очень дорогой фичи с подмножеством языка.
Я не о примитивщине на регэкспах говорю. Я о бизнес-логике говорю. О взаимной зависимости полей. Регэкспами такое не выражается. Например, есть у нас два поля, в которых значения выбираются из двух списков, но вот не все сочетания значений разрешены.
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, novitk, Вы писали:
N>>Язык без батареек никому нужен, а большинство батареек у питона на C/C++. Варианты решения твоей проблемы: N>>а) Пишем валидатор на JS, на питоне подключаем через https://github.com/sqreen/PyMiniRacer или что-то похожее N>>б) https://github.com/pyodide/pyodide, но тяжелая артиллерия
С>Вы, как и прочие участники треда, не понимаете задачу.
Звучит как нужно просто форму и её валидацию запрограммировать как такую модель из кирпичиков один раз, и дальше сделать реализацию кирпичиков для питона и для JS. Задача очень узкая и нетипичная, и ожидать для неё готовое общее решение по-моему не стоит.
С>А она достаточно частая и не требует "батареек". Допустим, у нас есть большая форма с 30 полями, и они между собой разумеется связаны. Там что-то рассчитывается, пересчитывается и проверяется. Это задача чисто алгоритмическая, и не требует ни рефлексии, ни наличия HashСode у каждого возможного типа, ни локализации строк, ни локалей для decimal'ов, ни горутин с async/await. Это может быть написано на паскале, на том самом, древнем процедурном.
Ну это вот здесь и сейчас батарейки не нужны, а в реальности часто оказывается, что бац — и теперь внезапно нельзя все данные заранее на клиент выгрузить, и надо ходить в базу например.
С>Ну и чего ради надо писать обвес вокруг валидации и перерасчёта два раза? На бэке и на фронте. А ведь писать-то придётся, причём со страданиями, потому что подобные формы, например ипотечные или страховые, пишутся по указаниям специалистов по предметной области.
Вот — моделировать формочки и по моделям обрабатывать и на фронте и на бэке, и ещё и документацию генерировать.
