Т
Ну очевидно что любая архитектура так или иначе подразумевает разделение работы с апишкой, бизнес логику и работу с базой. Так же очевидно, что коннекторы БД обычно принимают datetime
+
Size: a a a
2020 July 24
T
Мне почему-то кажется, что подмножество БД, которые принимают тип Integer не меньше подмножества БД, которые принимают тип Date/DateTime
Мне почему-то кажется, что типичные операции с датами удобнее делать с типом datetime чем с числом
T
Мне почему-то кажется, что подмножество БД, которые принимают тип Integer не меньше подмножества БД, которые принимают тип Date/DateTime
Приведи пример
<Ч
Может дата в json в виде int потому что в json нет формата для даты?
T
Может дата в json в виде int потому что в json нет формата для даты?
Ага, а объекты словарями
ЕП
Вопрос: зачем писать свой промежуточный слой, когда уже есть промежуточный слой под названием aiogram?
В том, что будучи aiogram самостоятельной библиотекой, которая бы реализовала свой некоторый API — вопросов нет. Делай, как хочешь, только задокументируй. И все счастливы.
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
<Ч
И это ограничение формата, а не какой-то там сознательный выбор
T
В том, что будучи aiogram самостоятельной библиотекой, которая бы реализовала свой некоторый API — вопросов нет. Делай, как хочешь, только задокументируй. И все счастливы.
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
Окей, зачем тогда aiogram словари превращает в объекты?
T
В документации словари
Т
В том, что будучи aiogram самостоятельной библиотекой, которая бы реализовала свой некоторый API — вопросов нет. Делай, как хочешь, только задокументируй. И все счастливы.
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
По доке chat_id может быть строкой 😁
<Ч
По доке chat_id может быть строкой 😁
+, поленился писать
T
В том, что будучи aiogram самостоятельной библиотекой, которая бы реализовала свой некоторый API — вопросов нет. Делай, как хочешь, только задокументируй. И все счастливы.
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
Но когда ты реализуешь обёртку над имеющимся API, по сути, портированием его, будь любезен следовать документации к API.
Так можно докатиться до того, что user_id будем строкой возвращать. А хули — всё равно в «"99 случаех из ста" (с) Токсик» мы этот ID покажем юзеру в текстовом сообщении
В этом суть обертки - взять сырые данные и представить из в удобном в данном языке виде
EK
В документации словари
"Это совсем другое!" (с)
ЕП
По доке chat_id может быть строкой 😁
где?
<Ч
где?
В каждом методе
ЕП
В документации словари
Для удобства и всяких крутых фич, разумеется.
Только в документации Message, User и Chat — тоже объекты, а содержимое — их поля. Загляни в документацию.
Поэтому их преобразование в питонячьи классы выглядит натурально.
Только в документации Message, User и Chat — тоже объекты, а содержимое — их поля. Загляни в документацию.
Поэтому их преобразование в питонячьи классы выглядит натурально.
EK
Поле которое называется date и представлено в виде объекта datetime выглядит тоже крайне натурально, нет?
ЕП
В каждом методе
В методе отправки? Так и в чём проблема? В aiogram тоже chat_id в каком-нибудь sendMessage может быть строкой или числом
EK
И что вообще по твоему "натурально"?
То что тебе в голову пришло для какого-то левого юзкейса?
То что тебе в голову пришло для какого-то левого юзкейса?
T
Для удобства и всяких крутых фич, разумеется.
Только в документации Message, User и Chat — тоже объекты, а содержимое — их поля. Загляни в документацию.
Поэтому их преобразование в питонячьи классы выглядит натурально.
Только в документации Message, User и Chat — тоже объекты, а содержимое — их поля. Загляни в документацию.
Поэтому их преобразование в питонячьи классы выглядит натурально.
Очевидно, что документация под "объектом" подразумевает не тип, а набор полей словаря