и в либе

можно конечно Raw взять

Ну можно кастом филд сделать

>на основе искуственного интеллекта УХ

А что такого?

В последнее время много бизнеса переходит на ИИ чат ботов

А что такого?

проблема называнием "ИИ" всего подряд

В последнее время много бизнеса переходит на ИИ чат ботов

лол, нет

В последнее время много бизнеса переходит на ИИ чат ботов

ии не существует

вот вот

существует и именно поэтому не проходит тест тьюринга

корректно называть их интелехтуальными системами

Использую библу requests во время подключения должна возникунть ошибка подключение timmeout error, но переодически проходит и ошибки не возникает ловлю следующую ошибку requests.exceptions.ConnectionError. В чем может быть проблема?

но никак не ии

Подскажите, у меня в поле может быть строка или bool. Как в marshmallow такое сделать?

имхо, лучше избегать такого

имхо, лучше избегать такого

увы, какое API дали

там на самом деле в зависимости от другого поля будет разный тип

полиформные схемы

вопрос не по теме

я что-то с опасением к ним отношусь

корректно называть их интелехтуальными системами

Слабый ИИ?

вы когда-нибудь слышали чтобы очередь называли стеком?

вы когда-нибудь слышали чтобы очередь называли стеком?

ну очереди обычно FIFO, а стэк - LIFO

я что-то с опасением к ним отношусь

я тоже, но увы.

у меня тут препод из универа работает, грит есть FIFO и FILO стэки

хехе

я ему сказал что fifo это очередь

бывает загон

спорить начал

я скорее наоборот слышал

fifo и lifo очереди

fifo и lifo очереди

это по-крайней мере для русскоязычного больше смысла имеет

корректно называть их интелехтуальными системами

Вычислительный ии. Но да, таки автоматический коррелятор

у меня тут препод из универа работает, грит есть FIFO и FILO стэки

ни разу не слышал чтобы FIFO называли стэком

ни разу не слышал чтобы FIFO называли стэком

ээээ, это и есть стек

бля, FIFO конечно же

у меня тут препод из универа работает, грит есть FIFO и FILO стэки

возможно он под термином стек имеет в виду форму хранения данных, где элементы идут один за другим, но все равно как-то странно

опечатался

может в железе это имеет смысл

где элементы идут один за другим, ну т.е. очередь :D

где элементы идут один за другим, ну т.е. очередь :D

не куча ?

оке

ии не существует

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

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

почему нет

где элементы идут один за другим, ну т.е. очередь :D

массив.

очередь - это формат доступа, массив - способ хранения =)

имхо

очередь - это формат доступа, массив - способ хранения =)

+

массив.

bytearray()

Очередь/стек - интерфейсы

не совсем

интерфейс может быть один - put и pop методы

а вот логика - разная

очередь - это формат доступа, массив - способ хранения =)

This

Логика работы push/pop - часть интерфейса

Просто невысказываемая в синтаксисе яп

ну я под интерфейсом именно технический понимаю

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

Тада бы в них не было смысла. Это было бы просто совпадение имен

ERROR: S client not available

Мы чего-то ожидаем от интерфейсов

когда тебе надо просто хранилище с возможностью по одному жлементу класть и доставать

я тоже, но увы.

я бы две разные схемы сделал

когда тебе надо просто хранилище с возможностью по одному жлементу класть и доставать

Я потерялся, если это мне

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

ой нафиг

у меня там и так там парсеры из схем делаются и потом инжектятся, везде дженерики. Туда ещё наследования не хватало

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

у меня там и так там парсеры из схем делаются и потом инжектятся, везде дженерики. Туда ещё наследования не хватало

ну наследование тут не добавит какой-либо сложности, это просто чтобы не копипастить поля

а потом на основе этих двух схем сделать oneofschema: https://github.com/marshmallow-code/marshmallow-oneofschema

ну наследование тут не добавит какой-либо сложности, это просто чтобы не копипастить поля

так мне придется вместо одного класса юзать несколько

так мне придется вместо одного класса юзать несколько

не, на выходе oneofschema у тебя так же будет одна схема

а не запилить ли мне в свою либу полиморфный парсер?

не, на выходе oneofschema у тебя так же будет одна схема

а толку? Датакласс мне потом все равно с union получится же?

а толку? Датакласс мне потом все равно с union получится же?

ну может быть два датакласса, либо датакласс-generic

ну может быть два датакласса, либо датакласс-generic

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

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

это у тебя входные параметры для api handler'а?

у меня щас типа Parser = Callable[[Dict], T] абстрактный класс Handler[T] и Broker[T] с init(parser: Parser[T], handler: Handler[T]) broker = Broker[Message1](message1_parser, handler1)

на самом деле чуть сложнее, но не суть

Ребят кто нибудь парсил яндекс зен?

у меня щас типа Parser = Callable[[Dict], T] абстрактный класс Handler[T] и Broker[T] с init(parser: Parser[T], handler: Handler[T]) broker = Broker[Message1](message1_parser, handler1)

ну так у тебя может быть Message1[str] и Message1[bool]

либо Union[Message1Str, Message1Bool]

ни разу не слышал чтобы FIFO называли стэком

Fifo - очередь, lifo - стэк.

ну так у тебя может быть Message1[str] и Message1[bool]

А. упустил. class Handler1(Handler[Message1]): ...

хэндлеры все не generic ибо нельзя

Ребят кто нибудь парсил яндекс зен?

Программисты были В ШОКЕ, когда попытались распарсить Яндекс.Дзен. Они нашли в коде древнюю……

Программисты были В ШОКЕ, когда попытались распарсить Яндекс.Дзен. Они нашли в коде древнюю……

империю инков

чозаяндексдзен