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

Написать requirements.txt

а подробнее мона?

AssertionError: Error, sync query is not allowed!

Тогда сделай так: asyncio.ensure_future(тут вызов твоей корутины)

не помогает

а подробнее мона?

pip freeze > requirements.txt

тогда пользователю достаточно будет сделать pip install -r requirements.txt

а подробнее мона?

Открой на github любую нормальную библиотеку и посмотри файл requirements. Станет ясно

может забить и прописать синхронно

не помогает

Что написал, покажи? Какой результат?

AssertionError: Error, sync query is not allowed!

тогда пользователю достаточно будет сделать pip install -r requirements.txt

хотелось бы вообще без каких-либо действий со стороны пользователя

и у них примеров нет как peewee-async юзать селект запросы

хотелось бы вообще без каких-либо действий со стороны пользователя

pyinstaller?

и у них примеров нет как peewee-async юзать селект запросы

Эм, а зачем execute? 0_o Чот я давно пиви не юзал

Эм, а зачем execute? 0_o Чот я давно пиви не юзал

потому что это peewee-async оболочка над пиви для асинхронности

Там же проще всё, ты связь в модели пишешь и даёшь ей имя. И тогда user.referrals уже тебе будет селект давать

потому что это peewee-async оболочка над пиви для асинхронности

Кэп)

Там же проще всё, ты связь в модели пишешь и даёшь ей имя. И тогда user.referrals уже тебе будет селект давать

что это за связь такая то

что это за связь такая то

Доку обычного пиви почитай, там есть. С телефона долго тебе объяснять буду

короче вот так работает, будет синхронно

Разве костыли удобнее? Если хочешь синхрон, тогда удали peewee async и пользуйся нормальной peewee. Или разберись с тем, что выше написал (про связи)

int object is not callble

В какой строке?

Привет, ребята.

Есть религиозный вопрос

должна ли валидация данных включать еще и приведение этих данных к типу, указанному в схеме?

всхеме чего?

должна ли валидация данных включать еще и приведение этих данных к типу, указанному в схеме?

нет, это же валидация должна кидать ошибочный тип

в схеме данных

нет, это же валидация должна кидать ошибочный тип

отлично, кто еще как думает?

смотря как данные приходят в скрипт

first window 1 QObject::moveToThread: Current thread (0x20e58a0) is not the object's thread (0x214fbc0). Cannot move to target thread (0x20e58a0) Ошибка сегментирования (стек памяти сброшен на диск) шо делать мля?

это что за пздц?

смотря как данные приходят в скрипт

да пофигу как

#Работа Python разработчик Вакансия:https://moikrug.ru/vacancies/1000044955 - Вилка 60-120 на мидла, 120-180 на ведущего/лида - Фулл-тайм - Удаленно [Ссылка] Требуется «Python разработчик» https://moikrug.ru/vacancies/1000044955

переменная u

переменная u

скобка блет

переменная u

то что переменная, это понятно. откуда скобка взялась?

это что за пздц?

опеатка, не?

опеатка, не?

я хз, возможно

либо переоперделение операторов, это не какой-нибудь хитровыебанный орм?

полностью строку покажи

а, ну да

ну вот все и стало ясно

переопределениеоператоров

все окей

ааааа бля, ахахахах)))))

тэкс, вопрос с валидацией актуален

Это же валидация

Она не должна изменять данные

Только проверять

Так что если пришли фиговые данные - ошибочка

Друзья, подскажите что можно использовать для работы со сканером для python3?

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

Друзья, подскажите что можно использовать для работы со сканером для python3?

драйвер сканер?

тадам

должна ли валидация данных включать еще и приведение этих данных к типу, указанному в схеме?

приведение данных - это уже нормализация

Это же валидация

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

типа, разрешаю любые итераблы, но хранить буду в листе

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

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

Ещё есть идея посмотреть в исходники джанговских формочек или на них проверить Если "123" пройдёт в integerField , то все окей

В джанговских формах при валидации часто приводят к правильному виду

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

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

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

ну это само собой, тут именно разговоро о том, что приведение внутри схемы нужно оставить

В какой строке?

уже не надо я из списка сделал тупл и так сравниваю

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

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

и уже сам может как угодно привести их(хоть строку в объект по-хитрому десериализовать)

Можно объединить валидацию и нормализацию

ну это само собой, тут именно разговоро о том, что приведение внутри схемы нужно оставить

тогда я бы обратил внимание на размер. Если он не большой, то я бы забыл и разделил.

ну вот мне объединение не нравится совсем

если большой, то подумал. Может и оставил бы

если большой, то подумал. Может и оставил бы

ну хз, а профит от этого?

в чем плюс объединения нормализации и валидации при больших размерах данных?

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

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

хорошее замечание

в чем плюс объединения нормализации и валидации при больших размерах данных?

всего один проход по массиву данных?

всего один проход по массиву данных?

ну, это насколько же большие данные должны прходить?

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

всего один проход по массиву данных?

но вообще тоже замечание неплохое

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

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

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

да и получается, что мы пытаемся нормализоавть данные, которые могут и не нормализоваться)

я про подход, а не про конкретную реализацию

ну, это насколько же большие данные должны прходить?

зависит же) Но скорее всего достаточно большими. Скорее всего прикладые вэбные задачи не даёт таких кейсов. В таком случае, я бы делал раздельно валидатор и нормализатор. Просто я хотел сказал, что в некоторых случаях написать оптимально важнее, чем "красиво", это редко, но так бывает :)