Есть бесчисленное множество Python-пакетов, которые легко добавить в любой проект. Но также есть несколько пакетов, которые вы просто не можете не использовать в любом веб-приложении на Django, потому что они зарекомендовали себя как чрезвычайно полезные и экономящие время.
Мы решили сосредоточиться на тех пакетах, которые в конечном итоге вы будете устанавливать регулярно, и рассказать об установке, а также конфигурациях, необходимых для их приведения в состояние готовности к работе.
В то время как некоторые Python-пакеты предлагают потрясающую функциональность, необходимую для конкретного проекта, пакеты, обсуждаемые ниже, — наиболее ходовые из Django-пакетов.
Сегодня я буду писать о Django — фреймворке, который верно служит мне на протяжении последних пяти лет. Он помог мне преуспеть в разработке высоконагруженных решений, используемых сегодня миллионами пользователей.
Действительно, Python не очень «быстрый» язык программирования, однако он прост, удобен и люди его любят. С точки зрения производительности, он не может быть таким же быстрым, как Go или Node.js, но это становится несущественным, если рассматривать современные инфраструктуры и модульную разработку.
Поскольку я уже несколько лет варюсь в этом «котле разработки на Django», я пришел к нескольким ценным выводам, которыми собираюсь с вами поделиться.
Привет, Хабр! Меня зовут Алексей Назаров. Я занимаюсь автоматизацией в отделе администрирования инфраструктурных систем в Национальной системе платежных карт (АО НСПК) и хотел рассказать немного о наших внутренних продуктах, которые помогают нам развиваться.
Если вы еще не читали пост про нашу инфраструктуру, то самое время! После прочтения этого поста я бы хотел рассказать о некоторых внутренних продуктах, которые мы разработали и внедрили.
Началось всё с того, что мне предложили в рамках предмета "Основы веб-программирования" поучаствовать в проекте, вместо проделывания лабораторных работ и курсовой, поскольку я заявил о том, что хотел быть делать нечто отдалённое от общего курса (и так уже достаточно знаний было по связке DRF + Vue, хотелось чего-то нового). И вот в одном из своих PR на github я решил использовать полнотекстовый поиск (задание намекало на это) для фильтрации контента, что заставило меня обратиться к документации Django в поисках того, каким же образом лучше это дело реализовать. Думаю, вы знаете большую часть из тех методов, что были там предложены (contains, icontains, trigram_similar). Все они подходят для каких-то конкретных задач, но не слишком хороши в, именно, полнотекстовом поиске. Пролистав чуть ниже, я наткнулся на раздел, в котором говорилось о взаимодействии Django и Pgsql для реализации document-based поиска, что меня привлекло, поскольку в постгре встроен инструмент для реализации этого самого [полнотекстового] поиска. И я решил, что скорее всего, django просто предоставляет API к этому поиску, исходя из чего такое решение должно работать и точнее и быстрее, чем любые другие варианты. Преподаватель мне не слишком поверил, мы с ним поспорили, и он предложил провести исследование на эту тему. И вот я здесь.
Мне в ходе разработки часто приходится работать с моделями, в которых должны быть изображения. Для удобной организации я использую древовидную структуру папок. В целом, Django предоставляет инструмент для работы с изображениями. Например, вот вопрос на Хабр Q&A о том, как работать с пикчами в Django: использовать ImageField
class Article(models.Model):
title = models.CharField(max_length=255)
content = models.TextField()
img = models.ImageField(upload_to='/article', height_field=100, width_field=100)Параметр upload_to указывает название папки, в которую нужно загрузить вашу пикчу. И получается, что в рантайме мы никак не сможем повлиять на место куда будет загружено ваше изображение. Выходит что для одной модели, все изображения будут складываться в одну папку. Беспорядок и непорядок какой-то в общем.
Всем привет. При разработке API для очередного веб-портала я взял свой привычный стек:
Но в этот раз стояла довольно непривычная задача — сделать одну User модель, которая может иметь несколько разных профилей (Исполнитель, Заказчик). И наличие каждого из профилей дает разные полномочия на работу с одними и теми же ресурсами.
Такой подход позволяет пользователям не заводить несколько учетных записей для каждой роли, что зачастую было бы невозможно, ввиду ограничений на модель: уникальный email или номер телефона.
Итак, опишем возникшие перед нами проблемы:
Ниже я приведу свой способ решения этой задачи, который сложился из уже наработанных привычек по организации Django-проекта, а также попыток придумать наиболее гибкое и масштабируемое решение.
from django.db import models
class Blog(models.Model):
name = models.CharField(max_length=250)
url = models.URLField()
def __str__(self):
return self.name
class Author(models.Model):
name = models.CharField(max_length=250)
def __str__(self):
return self.name
class Post(models.Model):
title = models.CharField(max_length=250)
content = models.TextField()
published = models.BooleanField(default=True)
blog = models.ForeignKey(Blog, on_delete=models.CASCADE)
authors = models.ManyToManyField(Author, related_name="posts")
Рано или поздно, разработчик на Django встречается с проблемой: как сделать так, чтобы пользователи не могли изменять или удалять, а то и вовсе не видели разные объекты одного и того же типа.
Допустим, ваш проект касается хранения информации о проектах. Разные пользователи входят в разные проекты и не должны видеть информацию о другом проекте. Один и тот же пользователь может входить в несколько проектов и иметь разный статус в разных проектах — где-то он может только просматривать информацию, а в других — править данные. В каком-то проекте пользователь зарегистрирован как персонал проекта, а в другом — только как потребитель его услуг. Уровень доступа соответственно, должен быть совершенно разным.
Этими вопросами занимаются несколько пакетов, мы рассмотрим один из них — Django-Access. Все, кому это интересно, приглашаются под кат.
Антон Патрушев – очень опытный python-разработчик, постоянный член программного комитета PyCon Russia и старый друг конференции. Он работает с языком python уже много лет, начинал свое знакомство с ним в Naumen, теперь является СТО в Spherical, а еще это была именно идея Антона провести PyCon в России.
Мы, организаторы PyCon Russia, поговорили с Антоном на парселтанге, и вот что получилось :)
gettext (установить его можно, например, командой pip install gettext). Если вы раньше не пользовались Django (популярным веб-фреймворком, основанным на Python), то вам, возможно, будет полезно сначала взглянуть на это официальное руководство, а потом вернуться к данной статье.