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.

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от blackst0ne

Я не понял, это в джангу завезли то, что в рельсах 100500 лет как было? Или я что-то не так понял?

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

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

Так тогда может лучше юзать Flask?

Flask имеет смысл если ты пишешь хелловорльд, а места на диске нет даже на 50МБ. Иначе нет смысла, придётся вручную ставить все аналоги джанговских компонентов, но на фласке.

А вообще мне джанговские контроллеры больше нравятся.

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

Да хоть с 1.10, ибо в 1.11 капитально переделали виджеты. Переделали, конечно, хорошо-годно, но пришлось тратить кучу времени на то, чтоб переписать все кастомные виджеты фактически с нуля

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

Допустимость отрицательных величин это уж совсем плохо.

Я сейчас заглянул в исходники Django — там по умолчанию юзается IntConverter, который на int назначает регулярку [0-9]+, то есть отрицательные числа недопустимы. Аналогично во Flask, кстати.

(А я бы хотел, чтобы были допустимы, приходится из-за этого со строками костылять)

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

Да, это тоже не слишком здорово. Во первых, кто мешал обозвать оного UintConverter? И вопросов не было бы.

А во вторых, почему нет защиты от переполнения? В питоне бесконечный int? Или ждем эпичную дыру?

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

а для тебя радость это обязательно пьянка и мордобой?

Как бы по теперешним традициям, любое празднование это пьянка. А разве пьянка это не скучно? А какие ещё варианты, кроме петь, плясать и устраивать оргии, в этом состоянии есть чтобы её преодолеть?

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

Да :) Пределы задаются только количеством свободной оперативной памяти, но длинные урлы пусть nginx не пущает)

Еще лучше. обычным интом всю память на сервере выбрать...

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

В реальности реализовать не получится. Интересен хотя бы теоретический вариант когда это возможно. Что за веб-сервер например наружу торчит или еще какой-то вариант деплоинга джанги.

У apache и nginx, например, максимум 8кб ты сможешь передать.

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

Еще лучше. обычным интом всю память на сервере выбрать...

Ну выставление ничем не прикрытого сервера наружу это уже лютое ССЗБ. Все адекватные production-ready серверы из коробки имеют ограничения как на длину урла (в районе нескольких килобайт), так и на длину всего тела HTTP-запроса (около 1 мегабайта у nginx)

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

Ну выставление ничем не прикрытого сервера наружу это уже лютое ССЗБ.

Выставление наружу не прикрытого всги-скрипта - это не просто ССЗБ, а, блджад, очень сильное колдунство.

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

Django — это не только wsgi-скрипт, но ещё и ./manage.py runserver. И изредка попадаются одарённые личности, которые не только вывешивают его в продакшен (вроде как даже через реверс-прокси это считается небезопасным), но ещё и запускают от рута, чтоб на порт 80 повесить

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

Когда Django и другие Python-фреймворки только изобретали, это ещё было не модно) И о надёжности встроенных серверов сильно не парились, объявили их серверами только для разработки да и всё

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

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

т.е. дофига

+100500. Походу там Поттеринг в девелы пролез.

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

Это уже не про безопасность, а про асинхронщину. И по этой теме джанга полная и абсолютно ненужная херота :D Хотя гугл намекает, что в aiohttp вроде можно запускать джангу, но по-моему это абсолютно бесполезное занятие, так как джанга синхронна чуть более чем полностью. Разве что с gevent запускать, но это уже gunicorn

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

У Flask дока не очень полная, новичкам не подойдет, а у джанги, как я понял, есть своя админка или апи, ее реализующее.

Сам использую фласк, жинжу и алхимию.

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

И по этой теме джанга полная и абсолютно ненужная херота

Как и Sanic, к сожалению. Только самые верные бойцы будут писать всё приложение в терминах async/await. Нормальные люди продолжат пилить на django или уйдут в го, где асинхронщина выглядит синхронно. Но это уже совсем другая история

makoven ★★★★★ ()