Ускорение производительности Python в 3.11

На данный момент заявляется полная обратная совместимость, конечно поживём-увидим, но я считаю, что им это удастся сделать, ибо под обратной совместимостью понимается две вещи: 1) запуск старого python кода, который работал на версиях 3.10, 3.9 и т.д. 2) совместимость с C API, которое используется, например, в numpy. Первая задача достаточно просто решается, и с ней проблем, я думаю, не будет, за исключением определённых вещей, которые будут удалены, т.к. устареют в этой версии, но если вы не используете депрекейтед код, то проблем не будет. А вот второе, это, конечно, задача по сложнее с точки зрения сохранения обратной совместимости, возможно, будет переходный этап, возможно, вообще не затронут конечные интерфейсы, объекты и в целом API, но одно ясно точно, это не будет такой же переход как с 2 на 3, а будет постепенное развитие, а не революция, Гвидо сильно против любой поломки совместимости. Главная цель - это ускорить так, чтобы ничего переписывать конечным пользователем не нужно было. Поэтому сейчас основная работа сосредоточена в ядре, то до чего руки обычных пользователей не дотягиваются или работа идет исключительно через обёртки.

Ускорение производительности Python в 3.11

только вот сейчас пересмотрел заново и не нашел ссылок на источник/источники, откуда эти цитаты!

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

Ускорение производительности Python в 3.11

Даже многие писатели пользуются и пользовались услугами по вычитке и корректировке текстов, т.к. допускали ошибки. Спасибо за секрет, но увы, не все опечатки они видят, например, вместо предлога "с", был написан случайно предлог "в" или опечатка в окончание слова, но слово читается и так и так верно(пропущена одна буква). Такого рода ошибки они не замечают, как и запятые в сложны местах или оборотах, а часть текста я дописал прямо здесь, в редакторе, не предполагая, что пропущенная запятая или тире вызовет столько комментов, для меня всегда важнее была смысловая часть)

Ускорение производительности Python в 3.11

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

Ускорение производительности Python в 3.11

Спасибо за бдительность, пропущенные буквы, лишние пробелы и запятые поправлены, не заметил данные опечатки при финальном прочтении материала.

Webpack 4 и разделение конфигурационного файла на модули

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

Webpack 4 и разделение конфигурационного файла на модули

Данная сборка была разработана под ОС Windows 10, так как большинство времени во front-end разработке проводится именно под этой ОС. В back-end разработке конечно же Linux используется мною как основная и главная ОС, но в данном случает под виндой всё работает идеально. А так замечание справедливое, можно сделать и так, если хочется, но у меня такой надобности не было.

Webpack 4 и разделение конфигурационного файла на модули

Модуль exports(module.exports = function(env, argv) ) может быть функцией, которая принимает env(environment) и argv, если сделать console.log(argv) внутри этой функции, и вызвать npm run build вы увидите кучу параметров(опций), в этом js объекте есть знакомый ключ — mode cо значением 'production'. А взялось это из скрипта(файл package.json), мы указывали, что при npm run build нужно использовать -> mode production, при start будет mode development.

Обновление Django с версии 1.9 до версии 2.0

Спасибо, учту в следующий раз)

Обновление Django с версии 1.9 до версии 2.0

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

Обновление Django с версии 1.9 до версии 2.0

Да согласен, не убрали, но я считаю изменить нужно обязательно, приведу аналогию: можно и дальше писать на функциях и не использовать CBV, что я считаю категорически не стоит делать, кроме каких то исключений, когда это оправдано, тем самым не использовать новый функционал, то же самое и тут, по этому изменить стоит, раз переписываем то всё, может в будущем старый метод устареет и будет удалён, кто знает)
За опечатку спасибо, поправлю)
В конце статьи написано, что если проект у вас большой, то и ошибок будет гораздо больше, к сожалению, под все проекты написать статью невозможно, данная статья была направлена как раз на основные нюансы обновления, которые свойственны всем проектам, а также она написана, для того что бы помочь быстрее разобраться с главными изменениями и приступить к обновлению.

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

Опят же то что вы написали не совсем корректно, работать можно не только через pk, но и через другие ключи(имя параметра, в котором передаётся интернет-адрес — в slug_url_kwarg, например), которые будут опираться на нужные поля в базе данных, нужное поле в бд, пишется в другом атрибуте. Так будет корректнее.

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

В частности, так и есть, но есть нюансы в реализации и в понимание. Советую тоже поработать с классами. Хотелось бы уточнить, я под pk имел введу, именно параметр — идентификатор. Это могут быть разные поля (соответственно разные регулярки), заданные либо pk_url_kwarg = 'pk', как первичный ключ, а в дальнейшем его можно преобразовать и изменить стандартную реализацию сортировки по бд(перехватить в методе ключ и изменить сортировку по любому полю), либо можно реализовать, так как вы предположили в теории, это реализуется с помощью slug_field(строка с именем поля модели, в котором хранится запись) + slug_url_kward. Забыл про эти атрибуты, посмотрел у себя в записях. Действительно реализовывать данную задачу можно по-разному. Но регулярка должна быть обязательно, которая передает значение, полученное из url адреса, в метод get. Ключ, по которому будет фильтроваться база данных в соответствие с параметром, должен быть. Сделать его можно разным (например, изменить работу pk, либо как написано выше) и задать по-разному, соответственно будет разная сложность. Но это все возможные варианты, больше нет. Я лично давно работаю с классами, всегда интересно практиковаться в них, функции уже давно не использую, считаю плохой практикой, и реализовывал сложные структуры с get, get_queryset, get_context_data, post.
. Но в данном рассуждение, действительно лично даже я для себя смог выявить и придумать много решений, которые потом попробую, но это уже на отдельную статью клонит, детальный разбор реализации DetailView и нюансы в работе. Надеюсь вам и читателям понравятся ещё вот такие способы, который я сейчас придумал и надеюсь я их не слишком сложно расписал, и они понятные. Так что можно либо моим способом, которые я написал в комментарии выше, либо способом с slug_field + slug_url_kward. Думаю, эти варианты сработают, всё же я не тестировал пока, но думаю сработают. Конечно более глубокое описание, тестирование и выводы, это уже полноценная статья, которая пишется не быстро, с редактированием и вычитыванием.

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

Я тут подумал, хотя если переопределить в DetailView атрибут slug_field методы get, get_queryset и обработать сложную регулярку из запроса(написанную в urls.py), и сделать её как pk, а в ней будет происходить обработка как раз всех адресов, то у нас может быть и получится вывести нужную страницу записав в одном из полей бд, поле, которое и будет отвечать за url адрес страницы, тем самым сделав одну запись. Но это я уже сам сейчас на ходу придумал) по этому наверняка не скажу реализацию, но попробовать потом можно) Я об это думал, когда разрабатывал данный метод и это тогда в голову не пришло тогда) А сейчас неожиданно пришёл в голову такой способ) Если вы что-то подобное имели введу, то расписали бы, так понятнее было бы, а так данный пост это пока что мои логические рассуждения, может кому-то поможет в дальнейшем такой вариант, который я сейчас предложил)

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

Отвечу по поводу DetailView, дабы не за блуждать людей, для этого базового класса нужно обязательно передавать pk в url, по которому будет искаться запись в базе данных(по этому я даже и не упоминал об этом классе в статье). По этому нет, такой способ не пройдёт, у вас будет ошибка. Ибо данный класс ждёт регулярку, в которой обрабатывается pk(ключ) и данный класс получает его с гет запросом, по которому ищет в дальнейшем запись. ( как пример из моего проекта — url(r'^blog/(?P\d+)$',..). А вот реализовать данный функционал, например, с помощью функции обработчика + те модули, которые написаны комментарием выше, это как раз можно, думаю, это как ещё одно элегантное решение, пока не испытывал, но можно, проблем не будет). Но в таком случае это лишь решение одной задачи. Тут же, я ещё упор делал на то, что админ может создавать сколько угодно страниц сам с различным контентом, а применение этому может быть широкое, вплоть до написания сайтов исключительно использующих данный функционал( такие сайты кстати есть, когда решал эту задачу, натыкался на статьи, где описывали крупные сайты, работающие исключительно на flatpages)
Насчёт вашего решения, в принципе да, можно так, неплохой совет, тоже как вариант)

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

На некоторые из ваших вопросов у меня есть ответы в текcте, а на которые есть в офф. документации (на часть ваших вопросов сразу может ответить документация). Надеюсь следующее сообщение поможет вам разобраться)

1. По поводу первого пункта(возможно не совсем корректно расписал, но так мне казалось будет понятнее для новичков), да у flatpages тоже будет отдельная запись в бд, но сразу со всеми данными, и самое главное, это то что не будет возможности на одну страницу добавить ещё данных из моделей (если создадим новый записи в базе данных, то наш шаблон в цикле их выведет на страницу, отсюда вёрстке ‘кирдык’, может так понятнее), как это делается в ListView, TemplateView.
2. Если вы знакомы, например, с ListView, то любая запись, добавленная админом, через цикл фор будет добавлена на страницу. Пример кода: ({% for object in object_list %}). В самом начале я написал, что данное поведение можно изменить, сделав, например, в get_queryset выборку лишь первой записи из бд, то же самое и с TemplateView(но в другом методе). Но это плохой тон, и я считаю делать так абсолютное неправильно. Опять же в предисловии более грамотно описано почему.
3. Без 'django.contrib.sites' flatpages не будет работать. См. документацию, см. мой пост, там я объяснил почему. У вас будет просто ошибка. Я усовершенствовал работу flatpages сделав нужную и полезную вещь для работы с простыми страницами, которые требует редактора контента для многих вот таких задач. “Cms в нано размере”. Ни где не написано, что расширять стандартный функционал джанги нельзя. Мне дали инструмент, я его улучшил) По-другому сделать никак нельзя, что бы одна модель (одна запись в бд) соответствовала одной странице. Лепить свой велосипед с нуля ещё хуже, а вот базовые классы не позволят этого сделать никак, только используя костыли в виде выборки из бд)
4. 4По поводу этого пункта, для полной работы со всеми прелестями этого редактора, было выбрано именно это поле. Возможно понадобится загрузка файлов в будущем для админа. Это уже больше архитектурное замечание (оптимизация базы данных, скорости и тд), нежели замечание работоспособности. Тут уже кто как хочет, так и делает, поэтому я изначально отсылал людей самим установить ckeditor.

Надеюсь я помог) Если у вас есть более лаконичное решение моей поставленной задачи, буду рад почитать на хабре:)

Расширяем и используем Flatpages в Django. Встраиваем CKEditor

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