Состоялся релиз web-фреймворка Django 3.0, написанного на языке Python и предназначенного для разработки веб-приложений. Ветка Django 3.0 отнесена к категории выпусков с обычным сроком поддержки и будет получать обновления до апреля 2021 года. LTS-ветка 2.22 будет поддерживаться до апреля 2022 года, а ветка 1.11 до апреля 2020 года. Поддержка ветки 2.1 прекращена...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=51989
жанга — ребенок строит на берегу песочный замокSpring Framework — команда архитекторов с двумя высшими образованиями проектируют бизнес-центр с десятком небоскребов
Толсто и с пальмовым жиром )
С гидрогенизированным - пальмовый жир не самое плохое на свете (даже тот дешёвый технический который в РФ кладут в продукты питания).В принципе жанга не самое плохое на свете, но мне больше нравится фласк. Может быть мои масштабы не те, но я не представляю вебни без питона и этот питон не жанга.
Flask хорош как для маленьких проектиков, где нужен быстрый старт, так и для огромных, где нужно много раз отходить от идеологии, и гибкость здесь очень ценится. Django как раз между, когда проект уже не маленький, но ещё не большой
Фласк для наколенных поделок. И быстрых прототипов. А джанга для больших проектов и работе с базой данных через какой-нибудь ORM. И если тебе нужна готовая админка. Что очевидно нужно не всегда.
К фласку что угодно можно прикрутить, мне он кажется гибче - меньше принуждения. А 99% "больших" проектов на джанге достаточно статики, имхо. 1% на инстаграм.
Там придется много долго что-то крутить, а в джанго бац и работает.
То-то и оно Flask обвешенный необходимыми ништяками очень быстро превращается в тот же Django, только там всё из коробки оптимизировано и готово к использованию, а в фласке с бубном придется поплясать...
>идрогенизированным - пальмовый жир не самое плохое на свете (даже тот дешёвый технический который в РФ кладут в продукты питания).Во-первых, это яд для организма. Во-вторых, аналогия с "пальмовым" маслом неуместна.
Ни один расиянец за всю свою жизнь никогда не попробует натуральное пальмовое масло, которое полезно. Если конечно он не поедет в тропики в деревню к туземцам.
Яд не яд, а 100% тортиков из него и состоят. Лучше уж нутелла с пальмой.
Инфа 146% !!!
как человек, неоднократно бывавший в тропиках, в том числе - в стране, у которой доходы от экспорта пальмового масла превышают доходы от экспорта нефти - докладываю: масло вам привозят - вполне натуральное. Оно настолько дешево, что нет ни малейшего смысла его подделывать. Это даже еще глупее чем подделывать, к примеру, подсолнечное.Местные туземцы в деревне - его не жрут. Вообще. Впрочем, их национальная жратва - возможно и здоровая, но совершенно отвратительна даже без пальмового масла.
Не забудьте прогреть все возможные кешы заведомо протерев все контакты сетевой инфраструкты спиртом.
Медленно взлетает зато далеко летит.
Это если памяти на машине бесконечно... простите, хватит. А иначе летает, как тот кирпич.
512 терабайт оперативы хватит на всех.
> 512 терабайт оперативы хватит на всех.Для хеллоуворлда сойдёт. А так надо бы с запасом уже.
Ну ещё на десяток следующих версий Electron должно бы хватить.
Вот что вы имели в виду этим сравнением? Что дельфины могут разломать песочный замок? И при чём тут дельфины вообще?
Если речь зашла о питоне для веба, то не дельфины или слоны (они тут сбоку припёка), а синий лещ.
Вот те раз... А я всё никак до 2.2 не доберусь, хотя вроде ничего принципиально нового...
Переход с 1.8 до 2.0 был достаточно болезненным (из коробки не завелся пришлось допиливать напильником) Сейчас вангую будет то же самое.
И поддержки год. Для чего это, для наколенных поделок, которые через полгода все, даже сам автор, забудут?
Между 1.8 и 2 изменений было в разы больше чем с переходом на 3, судя по списку...
В своё время товарищи создатели Джанго рекомендовали Postgre для новый проектов в Джанго Буке.If you're not tied to any legacy system and have the freedom to choose a database back-end, we recommend PostgreSQL, which achives a fine balance between cost, features, speed and stability. (The Definitive Guide to Django, p. 15)
Даже сейчас в Джанго поддерживается больше функций для Postgre чем для других баз данных.
А что не так то?
https://books.google.ru/books?id=Gpr7J7-FFmwC&pg=PA11&hl=ru&...
Вот именно по той причине трогать это оно настоятельно не хочется.
А что не так, по-твоему, с Postgre?
> А что не так, по-твоему, с Postgre?Всё. Задолбался объяснять. Унылый угрёбищный дизайн из прошлого тысячелетия. Если хочется энтерпрайза - берём кровавый энтерпрайз. Если хочется шустро и молодёжно - MySQL. А постгря - гибрид ужа с ежом, неудачный мичуринский эксперимент.
а ты поставь где-нибудь поближе к уху джанк с sqlite - это вполне поддерживаемая и одобряемая конфигурация - формально, во всяком случае.Полагаю, неистовый скрежет диска быстро тебе (как и мне когда-то) объяснит, почему так делать не надо, и постгрез с его многоуровневыми оптимизаторами и кэшами - единственный выбор для этого, очень правильно названного, джанка.
Потому что, внезапно, наворачивая десять слоев абстракции и изоляции вокруг уже и так достаточно абстрактного и изолированного языка sql - очень удивительно было бы не получить чудовищно неэффективную работу с базой, оптимизированной для совершенно противоположной задачи.
Но макакам, любителям громоздить фреймворки поверх фреймворков поверх фреймворков - по другому не работается.
> а ты поставь где-нибудь поближе к уху джанк с sqlite - это
> Полагаю, неистовый скрежет диска быстро тебе (как и мне когда-то) объяснит, почемуНе, ну ты сказал. Ещё давай из CSV'шников читать.
простите, но вы явно опытный фронтенд-разработчик, да?Ведь при чтении из точно такого же файла (внезапно, постгрез хранит базку - в файликах. Точно так же лежащих на той же самой файловой системе, правда, есть ньюансы - файликов там сильно не один, и их внутренняя структура - продукт оверинжиниринга и 90х годов прошлого века при этом) но через шестнадцать прослоек и двенадцать апи - происходит магия?
А скрипт для веб-сайта, берущий контент из csv файла - у меня, внезапно, есть, и вполне эффективно работает, совершенно не пытаясь прогрызть в диске дыру. Он еще и не виснет раз в три дня, как поделка на джанке.
Простите за глупый вопрос, а в админке теперь при выборе вложенного элемента все еще значение старое или сделали уже обновление поля? А то просто как-то митапы совещания и т.д. А выглядит все еще как детское поделие.
В админке для вложенных элементов по идее надо в функции update переопределять что ты хочешь там обновить.
Я про UI. Там где выбрали элемент в ForeignKey поле открывают отдельное окно, но после выбора элемента он не изменяеьтся в основной форме. Это вот прям сильно расстраивает.
Пощупал руками новую версию, и ощутил разочарование.На самом деле, все эти изменения - это просто асинхронная обертка вокруг синхронной, как и прежде, джанги.
По большому счету добавилось только возможность написать свое или использовать стандартное asgi-приложение с его мидлварями, а дальше идет запуск через переходник синхронщины. То есть, ничего в сущности и не изменилось, потому что сам фреймворк остался без изменений.
Так что, если кто-то, - как вот я, - ждал аснхронных вьюх работающих через тредпулэкзекутор с ОРМом (для начала хотя бы так), то этот "кто-то" сильно ошибся. Этого нет. И в ближайшей перспективе вряд ли будет.
Сплошное разочарование.
Вроде как собираются все это реализовать со временем, просто за раз сделать все асинхронным с совместимостью со старым кодом очень трудно, поэтому будут итеративно добавлять асинхронность.
С начала создали базу для перехода. Теперь будут переписывать компоненты. Об этом говорилось с самого начала. Что они делают не так?
Они все делают так. Но такими темпами, что когда они свое "все так" запилят, они обнаружат, что aiohttp, fastapi и прочие легкие асинхронные фреймворки давным-давно запилили свой (асинхронный же) ОРМ и обзавелись админкой - а именно этого им сейчас, ИМХО, недостает, - и большая часть народа уже сидит там, и мигрировать на джангу обратно не испытывает ну никакого желания.ЗЫ Кстати, вполне возможно что начинать нужно было с асинхронного ОРМа. Но это так... мое личное ИМХО.
Django использует много бизнес-решений. Если ты обновишь слишком быстро, то будет «ну мы это, как-нибудь потом перейдём». Поэтому нужно развивать, но более плавно.Мне очень нравится, что даже синхронная Django идёт в направлении asyncio.
Лично я чаще пишу на aiohttp/japonito, но у меня соответствующие требования к задачам.
"django, flask" - мне больше понравилось aiohttp + pwe. После первых двух - за день освоил и мне как-то больше в душу легло.
¿pwe — это что?
Это очередной высер Python-ястов только что бы не использовать нормальный Docker.
Сравнение разнотипных обьектов Django это фреймворк, а aiohttp библиотека HTTP сервера, а кроме HTTP сервера Вам еще нужно реализовать кучу всего начиная от шаблонизатора, базы данных и верно все это связать в одно решение. Кроме того в Django можно нагенерить админку двумя классами. Так что сравнение между рамой велосипеда и готовым кроссовером экономичного класса.
Во-первых, у этих фреймворков разные задачи.
Во-вторых, использование шаблонизатора в aiohttp возможно и можете использовать, какой вам нравится, даже от Django.
В-третьих, если вам так очень нужен ORM, то можно использовать часть SQLALchemy с обёртками для PgSQL и MySQL (aiopg и aiomysql)Если не очень нужен ORM (что чаще всего и бывает на самом деле, просто ну очень лениво написать пару SQL-statements), то можно использовать очень быстрый asyncpg. Он не может быть использован ни в SQLAlchemy, ни в Django (там обычно не нужна такая скорость и гибкость обработки данных)
PS; даже в Spring Framework сейчас общая тенденция отказываться от ORM в кровавым Энтерпрайзе