Питон специально создан для того чтобы его _хотелось_ читать

Спорное мнение

?

Окей, начну с Flask + SQLAlchemy, а там посмотрим =) В данном случае лучший ресурс документация?

А начинать - реальный проект или поиграться?

Спорное мнение

Спорное? Минуту

>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

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

Хорошо написанный код приятно читать на любом ЯП. Питон этим манифестом очевидное преподносит как свое преимущество

А начинать - реальный проект или поиграться?

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

>>> import this The Zen of Python, by Tim Peters Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!

давайте ещё вместе посчитаем сколько из этих пунктов нарушают исходники питона и его стдлиб :)

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

ну тогда вполне ок, но фласк нужно не стесняться достраивать до нужной кондиции

давайте ещё вместе посчитаем сколько из этих пунктов нарушают исходники питона и его стдлиб :)

не ошибается тот, кто ничего не делает ?

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

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

В go все гораздо проще, там мнение сообщества - “Пиши как вздумается, потому что у нас нет мнения по этому поводу, да и полное отстутствие сахара не даст тебе сделать ничего противоречивого.“

Где взять код?

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

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

иди читать PEP-8.

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

Да не, с этим проблем не будет, просто хочу понять как здесь принято решать задачи

иди читать PEP-8.

я?

?

я?

??‍♂️

ок… ?

смешно.

Да не, с этим проблем не будет, просто хочу понять как здесь принято решать задачи

Синхронный стек: джанга, фласк, иви, пирамид Асинхронный: аиохттп, саник, четамещёмодно

japronto

Синхронный стек: джанга, фласк, иви, пирамид Асинхронный: аиохттп, саник, четамещёмодно

Что значит синхронный/асинхронный?

Просто что значит - или в контексте ответа?

Просто что значит - или в контексте ответа?

В контексте

так пошутить хочется, но перегну

Всем привет! Перехожу с node.js на python, можете, пожалуйста, на чем сейчас пишут REST API, работу с БД? И, если не сложно, подскажите хорошие ресурсы где почитать как принято писать и структурировать соответствующие приложения?

Я с разрешения сообщества всё-таки топикстартеру верну вопрос: на чём сейчас пишут REST API, обращаются к БД и как принято структурировать код в node.js?

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

Я с разрешения сообщества всё-таки топикстартеру верну вопрос: на чём сейчас пишут REST API, обращаются к БД и как принято структурировать код в node.js?

Меня просто разрывает от вопросов по ноде в питон чате

В питоне относительно с недавних пор в языке есть async/await, он позволяет писать асинхронный код Писать асинхронно на синхронных фреймворках - не выйдет, писать синхронно на асинхронный фреймворках ?

как обновить нпм кто знает

как обновить нпм кто знает

?

Ну все же эксперты здесь. Возьмитесь меня научить кто-нить как правильно писать на питоне? Я даже готов заплатить. ?

как обновить нпм кто знает

rm -rf node_modules

Ну все же эксперты здесь. Возьмитесь меня научить кто-нить как правильно писать на питоне? Я даже готов заплатить. ?

http://docs.python-guide.org/en/latest/

Я с разрешения сообщества всё-таки топикстартеру верну вопрос: на чём сейчас пишут REST API, обращаются к БД и как принято структурировать код в node.js?

Без проблем: Основные веб-фреймворки Express, Koa и Hapi (Express сильно преобладает) Базы данных: Mongoose для MongoDB, Knex (и еще пара querybuilder-ов) для SQL. Не замечал, что сильно популярны ORM и сам с ними не работал. В последнее время очень популярно отходить от структурирования в стиле MVC на уровне приложения к модульной архитектуре где каждый модуль представляет MVC на уровне каждого ресурса в контексте REST.

rm -rf node_modules

apt-get python3

apt-get python3

python3 -c 'import this'

http://docs.python-guide.org/en/latest/

<irony>вот так всегда. только найдёшь вменяемых людей, которые знают как правильно - сразу RTFM. эх эх эх.</irony>

<irony>вот так всегда. только найдёшь вменяемых людей, которые знают как правильно - сразу RTFM. эх эх эх.</irony>

Внимательный читатель заметит, что это не ссылка на докементацию

Внимательный читатель заметит, что это не ссылка на докементацию

я знаю что это даже не открывая ?

Как настроить logging модуль, чтоб писал %(processName)s %(threadName)s только если они отличаются от MainProcess/MainThread?

пилить свой объект LogRecord? ?

Без проблем: Основные веб-фреймворки Express, Koa и Hapi (Express сильно преобладает) Базы данных: Mongoose для MongoDB, Knex (и еще пара querybuilder-ов) для SQL. Не замечал, что сильно популярны ORM и сам с ними не работал. В последнее время очень популярно отходить от структурирования в стиле MVC на уровне приложения к модульной архитектуре где каждый модуль представляет MVC на уровне каждого ресурса в контексте REST.

Поэтому мне и странно видеть, что за n лет существования pythona и, в частности, Django/Flask, в сообществе нет мнения относительно того как решить типовую задачу - реализовать REST API. Без разницы с mongo, postgres или redis. Это все-таки проблемы молодого сообщества типа golang, где есть 10 основных одинаковых роутеров, которые даже до Flask по функциональности недотягивают.

Как настроить logging модуль, чтоб писал %(processName)s %(threadName)s только если они отличаются от MainProcess/MainThread?

посмотри Filter Object раздел в доке

16.6.5. Filter Objects

рест это рест

Поэтому мне и странно видеть, что за n лет существования pythona и, в частности, Django/Flask, в сообществе нет мнения относительно того как решить типовую задачу - реализовать REST API. Без разницы с mongo, postgres или redis. Это все-таки проблемы молодого сообщества типа golang, где есть 10 основных одинаковых роутеров, которые даже до Flask по функциональности недотягивают.

нет "единого мнения" может быть?

питон это питон

моя ссаная тряпка это по тебе ссаная тряпка

за n лет существования питона - появилось n**m способов решить типовую задачу - реализовать рест апи

eve, drf, flask_restful (пожалуйста нинада)

за n лет существования питона - появилось n**m способов решить типовую задачу - реализовать рест апи

может ты не в курсе, но он пишет статистику для телеграма, стартап

за n лет существования питона - появилось n**m способов решить типовую задачу - реализовать рест апи

Так речь о том, что в молодом сообществе за год появляется n**m решений, а к зрелости остаются 1-2 библиотеки в любой области и 1-2 подхода как решаются задачи. Да, каждый делает как ему вздумается, но базовые вещи остаются базовыми

Так речь о том, что в молодом сообществе за год появляется n**m решений, а к зрелости остаются 1-2 библиотеки в любой области и 1-2 подхода как решаются задачи. Да, каждый делает как ему вздумается, но базовые вещи остаются базовыми

Нет, это не так работает

Поэтому мне и странно видеть, что за n лет существования pythona и, в частности, Django/Flask, в сообществе нет мнения относительно того как решить типовую задачу - реализовать REST API. Без разницы с mongo, postgres или redis. Это все-таки проблемы молодого сообщества типа golang, где есть 10 основных одинаковых роутеров, которые даже до Flask по функциональности недотягивают.

язык развивается, практики разработки тоже не стоят на месте, фреймворки рождаются и со временем умирают. от старости.

Так речь о том, что в молодом сообществе за год появляется n**m решений, а к зрелости остаются 1-2 библиотеки в любой области и 1-2 подхода как решаются задачи. Да, каждый делает как ему вздумается, но базовые вещи остаются базовыми

В умирающем сообществе остаётся руби он рейлс и погибает

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

если говорить про реальное рест апи, то ни на питоне, ни на жс - нет подходящих решений :)

если говорить про "рест" апи, то каждый дрочит как хочет

вот коретим принёс в питон asyncio, будь он неладен, и всё резко постарело. фласк уже не торт, и тп

пилить свой объект LogRecord? ?

А иначе никак?

А иначе никак?

Выше про фильтры ответили правильнее

если говорить про реальное рест апи, то ни на питоне, ни на жс - нет подходящих решений :)

eve на питоне

16.6.5. Filter Objects

Спасибо, ребят!

^ см про eve

Спасибо, ребят!

я ещё только учусь! меня правда в падаваны никто не хочет взять ?

пойду pep8 прочту на ночь 3 раза ?

True!

<irony> не забудь добавить!

когда интернету без разницы - разработчик ты citypy или нет :)

citypy это что?

Ладно, всем спасибо, общее мнение отсительно того, как двигаться дальше я составил =)

Так речь о том, что в молодом сообществе за год появляется n**m решений, а к зрелости остаются 1-2 библиотеки в любой области и 1-2 подхода как решаются задачи. Да, каждый делает как ему вздумается, но базовые вещи остаются базовыми

Ну по сути из распространенных синхронных фреймворков есть Django/Flask. Из асинхронных tornado/aiohttp. У каждого из них есть по библиотеке для REST API. Мы же не берём сейчас все существующие js фреймворки и не говорим, что там десятки способов сделать rest api и до сих пор нет чего-то идиоматичного. Вот и с питоном не надо так.

Ладно, всем спасибо, общее мнение отсительно того, как двигаться дальше я составил =)

посмотри в сторону eve и hug.rest

Ну по сути из распространенных синхронных фреймворков есть Django/Flask. Из асинхронных tornado/aiohttp. У каждого из них есть по библиотеке для REST API. Мы же не берём сейчас все существующие js фреймворки и не говорим, что там десятки способов сделать rest api и до сих пор нет чего-то идиоматичного. Вот и с питоном не надо так.

Идиоматичное как раз есть

т.е. саник не подойдет?

т.е. саник не подойдет?

Нет

Ну по сути из распространенных синхронных фреймворков есть Django/Flask. Из асинхронных tornado/aiohttp. У каждого из них есть по библиотеке для REST API. Мы же не берём сейчас все существующие js фреймворки и не говорим, что там десятки способов сделать rest api и до сих пор нет чего-то идиоматичного. Вот и с питоном не надо так.

Я не из этого выводы делаю, просто изначально следовали ответы в формате “серебрянной пули нет”

Идиоматичное как раз есть

Ну вот и в питоне есть идиоматичные Django и Flask.

когда интернету без разницы - разработчик ты citypy или нет :)

БЛИН!!! Я вспомнил! Это же мы с Юрой Юревичем поднимали сайтец 10 лет назад. Он жив ещё оказывается! Чудо

:)

Я не из этого выводы делаю, просто изначально следовали ответы в формате “серебрянной пули нет”

Ну, ее действительно нет.

Ну вот и в питоне есть идиоматичные Django и Flask.

Джанго может быть. Фласк точно нет

Джанго может быть. Фласк точно нет

э?

Ну по сути из распространенных синхронных фреймворков есть Django/Flask. Из асинхронных tornado/aiohttp. У каждого из них есть по библиотеке для REST API. Мы же не берём сейчас все существующие js фреймворки и не говорим, что там десятки способов сделать rest api и до сих пор нет чего-то идиоматичного. Вот и с питоном не надо так.

Если использовать Flask для REST API, то https://flask-restful.readthedocs.io/en/latest/ правильный путь?

Если использовать Flask для REST API, то https://flask-restful.readthedocs.io/en/latest/ правильный путь?

Вполне

э?

Во фласке ты волен делать что угодно не задумываясь. В Джанго тоже, но там больше телодвижений нужно сделать

А вот в eve .....)))

А вот в eve .....)))

eve на фласке

Если использовать Flask для REST API, то https://flask-restful.readthedocs.io/en/latest/ правильный путь?

нинада!