LINUX.ORG.RU

Django 2.0

 ,


2

5

Команда Django с радостью объявляет выход Django 2.0.

Django — веб-фреймворк, написанный на Python и реализующий паттерн model-view-template.

С этого релиза в Django будет использоваться свободная форма семантического версионирования. В этой версии нет крупных изменений, которые могли бы вызвать проблемы с обратной совместимостью (кроме отказа от поддержки Python 2.7). Обновление потребует столько же усилий, сколько требовали и предыдущие версии.

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

Вместе с релизом Django 2.0, основная поддержка Django 1.11 окончилась. Долгосрочная поддержка версии 1.11 продлится до апреля 2020 года.

Долгосрочная поддержка Django 1.10 окончена. Все приложения, использующие эту версию, рекомендовано обновить до версии Django 1.11.

>>> Подробности

Ответ на: комментарий от makoven

Чем тебе async/await выглядит не синхронно? Это ж не убогие промисы, как в джаваскрипте каком-нибудь (хотя и туда async/await недавно завезли), код от синхронного отличается по сути только словами async и await в нужных местах и больше в принципе ничем

andreymal ()
Ответ на: комментарий от andreymal

Вспомнил чей-то хабракомент по теме (середины 2016 года):

Пробывали писать на aiohttp, и… не получилось. В определенный момент пришлось переписать все на стандартном стэке Flask + SQLAlchemy. Aiohttp — хороший фреймворк для написания простых и плоских (flat) приложений (вроде todo-листа или веб-чата), но когда дело доходит до написания серьезных приложений, насыщенных ООП и с хоть какой-нибудь вложенностью, то делать это крайне тяжело. Поскольку любые функции для работы с БД должны быть корутинами, то и функции, вызывающие их, так же должны быть корутинами. В результате весь код превращается в одну большую корутину, со всеми вытекающими последствиями.

Ну об использовании ORM-фреймворков не может идти и речи, поскольку все они завязаны на динамике языке и использовании динамических @property и lazy-подгрузке данных из БД. Asyncio-проперти язык поддерживает, но это просто АДъ и реально работать с таким кодом нереально. В результате выхода два — либо писать sql-запросы прямо в коде (приехали), либо вообще не использовать реляционных БД и писать на том же Mongo (возвращаемся к вопросу о том, какие приложения на таком стэке можно реально написать).

makoven ★★★★★ ()
Ответ на: комментарий от makoven

В результате весь код превращается в одну большую корутину

Как будто что-то плохое

со всеми вытекающими последствиями.

Какими такими последствиями?

об использовании ORM-фреймворков не может идти и речи

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

Asyncio-проперти

Зачем они в ORM? В Django ORM пропертей, насколько я помню, нет. Точнее, есть такие проперти, которые возвращают QuerySet, но они ничего не делают, просто синхронно создаются. Проблемой может быть разве что работа с этим самым QuerySet, который при запуске цикла с ним лениво обращается к БД, но, ИМХО, ленивость не так уж и нужна, можно её выкинуть без существенной потери удобства. Собственно, я в своём коде и так всегда привожу QuerySet к спискам, чтобы запрос не выполнялся где попало, посреди шаблона например (тоже адок при отладке).

писать sql-запросы прямо в коде

Даже если отказываться от ORM, простые query builder'ы всё равно никто не отменял, чё в крайности впадать-то

Короче, ни о чём коммент как-то

andreymal ()
Ответ на: комментарий от makoven

Гугл намекает на существование асинхронных вариантов SQLAlchemy и Peewee. Но у меня асинхронных проектов, требующих ORM, пока не появилось (хотя в планах попробовать портировать один сайтец с Flask на Sanic), поэтому сам их пока не тыкал и про их готовность ничего не могу сказать

andreymal ()
Ответ на: комментарий от pawnhearts

Туда можно ставить что угодно.

Тут в соседних темах по питону обнаруживались некрофилы, добровольно работающие с какими-то древним редхатами и центосями, в которых из коробки только второй питон, а не из коробки не хотят :)

andreymal ()
Ответ на: комментарий от makoven

Не всегда. Но вообще не вижу принципиальной разницы типа «хочу писать только на 3-м». А переводить большой старый проект на более новую версию джанго порой не менее мучительно, чем переделать его под питон3.

pawnhearts ★★★ ()
Ответ на: комментарий от makoven

Хм, во многих случаях процессам не обязательно быть сильно связанными друг с другом и можно просто запустить несколько процессов и разбрасывать между ними с помощью nginx и т.п. Если там какие-то тормозные вычисления можно из их делать в подпроцессе неблокируещем или по сети обращаться. Например, у меня генерируются превьюшки в видео - я в неблокирующем режиме запускаю ffmpeg для этого. Это всегда как-то так делается. Плодить треды с какой-то работой в асинхронном сервере как-то странно для меня.

pawnhearts ★★★ ()
Ответ на: комментарий от andreymal

Ну так поэтому и лютое, что изначально такие косяки.

Что касается нжинкса, то ограничив тело ты ограничиваешь и размер загружаемых файлов.

AVL2 ★★★★★ ()
Ответ на: комментарий от pawnhearts

Мне лично доводилось поддерживать два (не моих) Django-сайта на shared-хостинге :)

(Весь набор соответствующих прелестей прилагался: версия джанги ископаемая, db.sqlite3 открыто торчит наружу и так далее)

andreymal ()
Ответ на: комментарий от meequz

с какой версии?

1.0 вроде. Просто проект у меня крутился где-то с 2009г. на шаред хостинге, а хостингу внезапно захотелось дропнуть старое окружение. Джанга у них была своя предустановленная, они решили отказаться от этой модели чтобы предоставлять только питон, а джангу-шмангу пользователи пусть сами ставят. Ну я подумал чё старьё тащить, попробовал портировать движок тот древний, который разработчик забросил давно...

pariyenodu ()
Ответ на: комментарий от pawnhearts

Плодить треды с какой-то работой в асинхронном сервере как-то странно для меня

Это язык накладывает ограничения на твой разум. Покури erlang. А вообще threadpool eventloop-ов это довольно стандартный подход

makoven ★★★★★ ()
Ответ на: комментарий от anonymous

Я тебя удивлю: swagger есть и для DRF и даже для tastypie, - это же уже почти отраслевой стандарт. Разница только в удобстве реализации.

Для DRF, ИМХО, он наименее удобный, а для flask наиболее (ну нравятся мне декораторы). Хотя у flask-restplus в Swagger-UI есть по меркам Django небольшой косячок: диалог сессионной авторизации отсутствует. Но это и понятно почему.

k0valenk0_igor ★★ ()
Последнее исправление: k0valenk0_igor (всего исправлений: 1)
Ответ на: комментарий от anonymous

Да ты шо?!

А люди и не знают и продолжают предлагать в среднем 120-150 штук в месяц (для локации Москва-Питер) за написание REST-бакэнда именно на Djange. АнонимчеГ иди их проконсультируй, они тебе будут признательны, - ведь ты своей консультацией сделаешь их день! Только это... жир со своего комента сотри. А то он такой толстый, что аж жирный))

k0valenk0_igor ★★ ()
Ответ на: комментарий от andreymal

а не из коробки не хотят

Вообще то уже давно из коробки в Шапке и 2й и 3й питон. Просто из того что из системы выкинули перл то многие системные скрипты переписали на питон2, вот он изначально и тащится в систему.

А всякие питоны3, рельсы5, php7 и подобное, давно есть из коробки, обслуживают всякую левую прикладную фигню аля сабжа.

P.S. Я правда хз как там в ПХП, но в случае Питона это все собрали для админов и энтерпрайза чтобы админы не особо парились с обновленем из-за заплатки в какой то очередной либе. А все это в питоне и так прекрасно делается через penv и virtualenv.

P.P.S. Хотя иногда интерпрайз идет еще дальше, лепят все в контейнерах и плевать.

mx__ ★★★ ()
Ответ на: комментарий от makoven

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

Но раз уж зашла речь, то есть еще один очень неплохой способ. Через rabbitmq. У него там есть очень интересный плагин дающий функционал веб-сокета связанного с конкретной очередью. И если заставить свой сервер слушать (и писать тоже) эту очередь, а клиента подвесить на сокет, то получится очень незатратное, по времени реализации, решение.

k0valenk0_igor ★★ ()
Ответ на: комментарий от k0valenk0_igor

Да я уже читал в 2014-15 от анонима тут на лоре истерики, что Джанга умерла, и никто на ней не кодит, что зарплаты как у php макак, и прочий трололо, в итоге, работа по django уже мазолит глаза, куда не глянь - если питон, то 50%, что джанга, причем в полном фарше со всякими rest/crud/elasticsearch.

menangen ★★★★★ ()
Ответ на: комментарий от WereFox

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

BigAlex ★★★ ()
Ответ на: комментарий от makoven

Haproxy в названии не случайно имеет слово прокси, которое означает «прокидывание/транслирование». Django это совсем другой уровень, это application server, он только генерирует контент, прокси же тупо обслуживает клиентов как посредник до http сервера (прокси может работать по tls/ssl, и распаковывать это, передавая уже http к http серверу). Так что и http server тебе тоже нужен в этой инфраструктуре. Существует несколько неплохих http серверов: nginx, lighttpd, apache, caddy, h2o, и прочие. Если ты не хочешь возиться со слегка упоротыми конфигами nginx, чтобы настроить его для джанги, то смотри в сторону мощного и довольно хорошего проекта Caddy, либо lighttpd (разработка которого снова ведётся).

menangen ★★★★★ ()
Ответ на: комментарий от menangen

Меня тоже веселят товарищи, утверждающие, что джанга пойдет только для бложика. Крупный питоновский проект с командой разрабов, веб или бэк - это сильно больше, чем 50% что джанга/drf. Потому что найти быстро нормального питоновского разраба на джангу, который будет сразу писать код сильно проще, чем на какой-нибудь фласк, где каждый дрочит как хочет с теми либами с которыми он привык.

BigAlex ★★★ ()
Ответ на: комментарий от Deliverance

Так 85% сайтов в Интернете работают поверх вордпресса, что как бы символизирует... посмотри на все эти 4pda, akket, 3dnews, appleinsider, 90% новостных сайтов в рф, это вордпрессина с уникальной темой, купленной за $40.

menangen ★★★★★ ()
Ответ на: комментарий от BigAlex

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

Тут не много не так. Любой питон программер без проблем осилит джангу и финты в ней. А вот если чел. ставит джангу и в ней что то минимально делает то он может быть питон и не особо понимать.

Тут как с рельсами. Каждый руби программер может РОР, но не каждый РОР может руби.

mx__ ★★★ ()
Ответ на: комментарий от menangen

Так 85% сайтов в Интернете работают поверх вордпресса,

Ну так админы накатывают ворд-пресс и все. Люди купившие сайт на вордпрессе и наполняющие его очень далеки от ПХП и вообще от программирования. ( еще много друпал пихают )

mx__ ★★★ ()

Так и не проникся. Может для сайтов уровня «я и мой кот» это нормальная «платформа», но в реальной жизни приходится работать с вещами посложнее «SELECT * FROM users;» и запихивания этого в <table>. И тут и админку эту хваленую приходится переделывать, и с ORM не все гладко, и вообще некоторые вещи сделаны так что не поймешь откуда ноги растут. В итоге проект превращается в какую-то вендошнягу, где ты сначала сутки ищешь в чем косяк и через что оно там работает, а потом за минуту правишь нужную строчку. А вот эта штука с «app» меня вообще убивает - кому нафиг это вообще сдалось?! Кто-то держит в одном «контейнере» сотню приложух чтоли? Лишний слой, добавляющий вот этих вот папочек и конфижечек. Жаль что как обычно самая шняга - в мейнстриме, и приходится писать на этом когда надо сделать и отдать. В тех случаях когда я знаю что поддерживать придется мне я эту жангу и двухметровой палкой ворошить не стану.

anonymous ()
Ответ на: комментарий от anonymous

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

Все зависит от того как и что добавлять. Может оказаться что ЭТО лучше на джанге и не делать. Опять же можно добавить правильно и тогда это будет ДРУГОЙ легко поддерживать так как ты сделал все правильно.

А вот если наколбасят так как ему вздумается то сам то потом забудешь не то что другой разберется :( Причем в случае не Джанги это ( наколбасить ) сделать проще ...

mx__ ★★★ ()