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

А что тогда читают крутые мужики?

man

Я только тут кстати вижу такой негатив к хабрахабру, в других сообществах такого не наблюдается.

я не согласен. Я вот наблюдал его и в других сообществах

Спасибо, гляну эти ресурсы

Можно из моих мультиреддитов посмотреть сабреддиты: https://www.reddit.com/user/teners/m/dev/ https://www.reddit.com/user/teners/m/linux/

крутые читают mailing lists python-dev ?

Можно из моих мультиреддитов посмотреть сабреддиты: https://www.reddit.com/user/teners/m/dev/ https://www.reddit.com/user/teners/m/linux/

кто ж палит свой реддит-username!

кто ж палит свой реддит-username!

Это public-username

ну.. такой пример. Зарт известный набрасывающий )

его тут покусали)

его тут покусали)

Кто? :)

я про то что он тоже одно время был в spbpython)

хых стикеры

я про то что он тоже одно время был в spbpython)

А из-за чего ушёл отсюда?

Матом запрещали ругаться

)))))

А из-за чего ушёл отсюда?

Тут слишком не rude python

Тут слишком не rude python

Аа, ну ясно. Не, rude - не моё.

хых стикеры

стикеры хороши

нам тоже такой пак надо собрать постепенно

сорян

о! demjson!

спасибо, пригодится)

нам тоже такой пак надо собрать постепенно

Мы лепили хэштег на годные сообщения, а потом проходились по хэштег и собирали предложенное

>However, we never paid too much attention to performance, so the net result is that with the latest released version of PyPy, C extensions generally work but their speed ranges from "slow" to "horribly slow".

/o/ типа нет ничего быстрее aiohttp в Python? чушь какая

скорее "не стоит ждать скорости от интерпретируемого языка".

Люди подскажите best Speech to Text(STT) and Natural Language Processing tools для Raspberry Pi(Rpi3) на питоне(желательно) Учитывая что у мини компьютер не такой мощный ?

Люди подскажите best Speech to Text(STT) and Natural Language Processing tools для Raspberry Pi(Rpi3) на питоне(желательно) Учитывая что у мини компьютер не такой мощный ?

думаю тебе в opendatascience slack

думаю тебе в opendatascience slack

отправил запрос) примут ли?

примут

нам тоже такой пак надо собрать постепенно

Желательно это не делать

почему? :) прикольно же

работает на атмосферу

работает на атмосферу

Это стагнация. У нас есть zen. Собственный стикерпак - идея годная, но делать из него цитатник - низ фантазии

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

Да, обсудим на itgm

?

Если вы каким-то чудом ещё не знаете, как прекрасен @PiterPy, то вот ваш шанс: https://habrahabr.ru/post/340902/

билеты покупаются на piterpy.ru. В конце статьи есть промокод со скидкой.

Добрый вечер

Кто может подсказать как в телеграм боте в методе SendPhoto в caption запихнуть URI в виде гиперссылки? Либо может кто подскажет как в URL засунуть URI? Сама задача состоит в том чтобы сделать текст который находится в caption метода SendPhoto в виде гиперссылки содержащей URI.

нинада

ну елы палы, ты читаешь что я тебе пишу в других чатах?

https://github.com/scipy/scipy/releases/tag/v1.0.0 16 лет до первой версии

>Для правильного REST надо его понимать до глубины души, и не идти на компромисы, а то получится кривой JSON-RPC

Было

>Для правильного REST надо его понимать до глубины души, и не идти на компромисы, а то получится кривой JSON-RPC

Это откуда?

>Для правильного REST надо его понимать до глубины души, и не идти на компромисы, а то получится кривой JSON-RPC

Это тоже из статьи мейлру?

>Для правильного REST надо его понимать до глубины души, и не идти на компромисы, а то получится кривой JSON-RPC

REST ради самого себя не нужен, лучше по свойствам ориентироваться. Но тогда оказывется, что в 99.99% случаев REST не нужен или нужен, но внедрение много сил и средств отнимет. Обычно архитектура так выстроена, что нужно data-oriented API с возможностью гибкой настройки получаемых данных. А REST ближе к message-oriented. Хотя я смешиваю в кучу разные классификации API.

REST ради самого себя не нужен, лучше по свойствам ориентироваться. Но тогда оказывется, что в 99.99% случаев REST не нужен или нужен, но внедрение много сил и средств отнимет. Обычно архитектура так выстроена, что нужно data-oriented API с возможностью гибкой настройки получаемых данных. А REST ближе к message-oriented. Хотя я смешиваю в кучу разные классификации API.

Rest message oriented? Мой мир перевернулся

Rest message oriented? Мой мир перевернулся

Я ж говорю, что в кучу смешиваю разные понятия ) Так-то REST resource-oriented. Но я видела такое количество текстов о том, что такое ресурс и как это понимать. Решила, что message будет понятнее. Hypermedia as a message :)

https://github.com/scipy/scipy/releases/tag/v1.0.0 16 лет до первой версии

Помню, как взялся за него как раз тогда, когда на NumPy перешли. На тот момент это было очень круто. И самое главное, что в этом самом 2005 году в нём уже всё было и всё работало, Карл! И только сейчас доехали до первой версии. Вот она - самокритичность ;). Вобщем мои поздравления проекту.

Rest message oriented? Мой мир перевернулся

хотя, похоже, я message в каком-то не том смысле употребляю, черт побери :(

REST ради самого себя не нужен, лучше по свойствам ориентироваться. Но тогда оказывется, что в 99.99% случаев REST не нужен или нужен, но внедрение много сил и средств отнимет. Обычно архитектура так выстроена, что нужно data-oriented API с возможностью гибкой настройки получаемых данных. А REST ближе к message-oriented. Хотя я смешиваю в кучу разные классификации API.

а вот vk api - это рест?

Кто учится сейчас в вузах программированию? Кто преподаёт сейчас программирование в вузах? Стукнитесь ко мне в личку, если можно, у меня к вам интересный вопрос возник на 1-2 минуты :)

Мить, запускай голосовалку по стажу/опыту).

Мить, запускай голосовалку по стажу/опыту).

знать бы варианты..

Кто учится сейчас в вузах программированию? Кто преподаёт сейчас программирование в вузах? Стукнитесь ко мне в личку, если можно, у меня к вам интересный вопрос возник на 1-2 минуты :)

Хе-хе :3

Хе-хе :3

ну-к не пали контору раньше времени )

хотя, похоже, я message в каком-то не том смысле употребляю, черт побери :(

Прочитал https://en.wikipedia.org/wiki/Message-oriented_middleware Мне кажется, что message-oriented относится не к REST API, а к ПО, которое состоит из распределенных компонентов, инфа между которыми пересылается через очереди сообщений.

а вот vk api - это рест?

Нет, у них один и те же ресурсы по разным url-aм запрашиваются, если надо получить ответ в виде другого представления. То есть это два разных ресурса, но по логике одно и то же, только один ответ принес xml, другой json. Гипермедиа не используется, в представлении нет инструкции, что следующим шагом можно сделать. И если уж следовать принципам REST, то документация должна быть посвящена кастомным content-type-ам, а не URI. Можно, конечно, сказать, что каждый URL - это отдельный RESTful сервис с одно точкой входа, одним вариантом представления, без каких-либо связей. Но смысл? Про кеширование в документации быстро найти не получилось.

Нет, у них один и те же ресурсы по разным url-aм запрашиваются, если надо получить ответ в виде другого представления. То есть это два разных ресурса, но по логике одно и то же, только один ответ принес xml, другой json. Гипермедиа не используется, в представлении нет инструкции, что следующим шагом можно сделать. И если уж следовать принципам REST, то документация должна быть посвящена кастомным content-type-ам, а не URI. Можно, конечно, сказать, что каждый URL - это отдельный RESTful сервис с одно точкой входа, одним вариантом представления, без каких-либо связей. Но смысл? Про кеширование в документации быстро найти не получилось.

спасибо! а как тогда в рамках rest сделать, например, профиль пользователя в вк? вот меняю я список своих интересов, фамилию, родной город итп. как это изменение положить на rest?

ERROR: S client not available

PATCH?

Или PUT как вариант.

Нет, у них один и те же ресурсы по разным url-aм запрашиваются, если надо получить ответ в виде другого представления. То есть это два разных ресурса, но по логике одно и то же, только один ответ принес xml, другой json. Гипермедиа не используется, в представлении нет инструкции, что следующим шагом можно сделать. И если уж следовать принципам REST, то документация должна быть посвящена кастомным content-type-ам, а не URI. Можно, конечно, сказать, что каждый URL - это отдельный RESTful сервис с одно точкой входа, одним вариантом представления, без каких-либо связей. Но смысл? Про кеширование в документации быстро найти не получилось.

Я вообще рекоммендую не париться о идиоматическом REST - это все искуственные ограничения которые не всегда приносят профит, хотя есть какие-то best practices которые все же удобны. Тем более, что для большого класса приложений, REST не хватает и нужен какой-то механизм уведомлений (вэбсокеты там, http2, etc...). Алсо, не вижу ничего фундаментально плохого в RCP-style API.

PATCH?

а если мы удаляем что-то?

а если мы удаляем что-то?

DELETE

Очень было интересно поработаь с Firebase - совершенно другая парадигма работы, жаль только vendor lock-in.

а если мы удаляем что-то?

Зависит от того, как организованы данные. Можно патчить пустой строкой или null, если такое решение подойдёт

Прочитал https://en.wikipedia.org/wiki/Message-oriented_middleware Мне кажется, что message-oriented относится не к REST API, а к ПО, которое состоит из распределенных компонентов, инфа между которыми пересылается через очереди сообщений.

Bingo

DELETE

и? в delete нельзя слать тело запроса

и? в delete нельзя слать тело запроса

ups, sorry)

Зависит от того, как организованы данные. Можно патчить пустой строкой или null, если такое решение подойдёт

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

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

Да null не особо и магическая, если данные строковые

и? в delete нельзя слать тело запроса

Если пошлёшь, то вселенная схлопнется?

Если пошлёшь, то вселенная схлопнется?

Именно

Ужасный rest

О боже, он послал ascii символ в теле delete

В печь restful инквизиции его

спасибо! а как тогда в рамках rest сделать, например, профиль пользователя в вк? вот меняю я список своих интересов, фамилию, родной город итп. как это изменение положить на rest?

Зависит от того, какие представления нужно передавать, будет ли использоваться HTTP кэширование. Потому что если надо завернуть разнородные объекты в один ресурс, а потом приходится часть из них завернуть в другой ресурс - то начинается боль, понятно, что тут нарушение принципов уже идет. Главное понять, что CRUD - это не REST. Вернее, наоборот, REST не ограничивается CRUD. Если набор действия укладывается в эту ббревиатуру, то хорошо, если нет, то без проблем можно использовать DDD и другие жуткие наборы букв :)

люди добрые, как думаете телеграм бота на пуле можно закидывать на сервак?) без сокетов)

Можно, если есть обработка ошибок

при connection error, re-run делать?)

при connection error, re-run делать?)

@botoid Отлавливать эксепшн и перезапускать поллинг

и? в delete нельзя слать тело запроса

Тут говорят, что прямо не запрещено: https://stackoverflow.com/a/299696 В комментах добавляют, что по стандарту сервер должен игнорировать тело у DELETE, потому что у него нет стандартной семантики, но «должен» там не «MUST», а «SHOULD», то есть можно и забить.

def run_bot(): try: s.call(["python", "бот_beta.py"]) except: print("ERRORRRRRRRRRRRR") pass while True: try: print("trying to connect") print ("time:",strftime("%Y-%m-%d %H:%M:%S", gmtime())) sleep(5) run_bot() except: print ("ERROR, Trying to reconnect") continue

В печь restful инквизиции его

Ну это http протокола ограничение. Троллинг тут не уместен

def run_bot(): try: s.call(["python", "бот_beta.py"]) except: print("ERRORRRRRRRRRRRR") pass while True: try: print("trying to connect") print ("time:",strftime("%Y-%m-%d %H:%M:%S", gmtime())) sleep(5) run_bot() except: print ("ERROR, Trying to reconnect") continue

Нет, точно не так

Кстати, а сокеты тут причем? Оо

))) хотя это работает на винде ахах, крона нет крон.пи создал для начала) linux сдох

типичный говнокодер )

Тут говорят, что прямо не запрещено: https://stackoverflow.com/a/299696 В комментах добавляют, что по стандарту сервер должен игнорировать тело у DELETE, потому что у него нет стандартной семантики, но «должен» там не «MUST», а «SHOULD», то есть можно и забить.

Там вообще в самом стандарте нет ни слова про то в каких методах можно, а в каких нельзя. Я искал. В трёх RFC - по нулям. При этом есть практика веб серверов падать в 500 в таких ситуациях. Типа, безопасность.