Skip to content

lesson19.md

Latest commit

 

History

History
886 lines (569 loc) · 49.3 KB

lesson19.md

File metadata and controls

886 lines (569 loc) · 49.3 KB

Лекция 19. Знакомство с Django

Как работает интернет, и что именно мы будем изучать?

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

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

Когда вы набираете в браузере URL или просто переходите по закладкам или ссылкам, на самом деле, вы заставляете браузер создавать и отправлять GET http-запрос. А когда вводите имя пользователя и пароль, чаще всего после кнопки, например, "Войти", вы формируете и отправляете POST http-запрос.

Request-response, он же клиент-сервер

Чаще всего при работе с веб-ресурсами мы будем иметь дело с так называемым взаимодействием запрос-ответ, что на английском звучит как request-response.

А это значит, что у нас есть кто-то, кто "спрашивает". И кто-то, кто "отвечает".

Кто может спрашивать?

На самом деле спрашивать может любое устройство или приложение, которое способно сформировать http запрос, а в современном мире это уже почти любое устройство, включая чайники, часы и стиральные машины.

Но в самом распространённом варианте это всё-таки будут:

  • Веб-браузеры (Chrome, Mozilla, Opera, их мобильные аналоги и т. п.)
  • Приложения (Instagram, Telegram и т. п. Приложения бывают не только мобильные, но и для компьютера или планшета, и мы даже будем ими пользоваться в рамках курса)

Кто может отвечать?

Отвечать может только сервер.

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

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

А бывает ли не клиент-сервер?

Бывает, но используется крайне редко, и для очень специфических случаев. Так что для нас не несёт полезной информации.

Краткое описание http запросов

Из чего состоит http запрос можно почитать тут, но, если вкратце, то из тела, где хранятся данные, и хедеров, где хранится служебная информация.

Метод GET

Используется для запроса содержимого указанного ресурса. Например, получить данные, файл или любую другую информацию, браузер (Chrome, Mozilla, etc.) при вводе url (https://ru.wikipedia.org/, https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=0s) использует именно GET запрос, может передавать переменные в query параметре (в примере с YouTube ?v=dQw4w9WgXcQ&t=0s - это query параметры, первый параметр начинается с символа ?, следующий параметр добавляется при помощи символа &, в данном примере параметр - это словарь {'v': 'dQw4w9WgXcQ', 't': '0s'}).

Обычно не используется для отправки данных (query параметры чаще используются для уточнения того, что вы хотите получить, например, значения фильтров или каких-то системных параметров).

Например, получение комментариев к посту в блоге, или списка рекомендаций на YouTube, открытие любого сайта это уже GET запрос.

Метод POST

Применяется для передачи пользовательских данных заданному ресурсу. Если мы хотим ввести имя пользователя и пароль, обычно мы используем POST, потому что это передача пользовательских данных. Хотим оставить комментарий - POST, заказать товар из интернет-магазина - POST, и т. д. Практически всегда, когда мы отправляем пользовательские данные, это будет POST.

Методы PUT и PATCH

Применяются для обновления данных. Например, изменить текст сообщения или пароль пользователя. Подробно будем разбираться с ними и с методом DELETE в следующем блоке этого курса.

Метод DELETE

Используется для удаления объектов. Подробно рассмотрим в следующем блоке.

Методы TRACE, HEAD, OPTIONS и т. д.

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

Шаблон проектирования MVC

Для разработки сложных решений используются шаблоны проектирования (patterns).

Если вы собираетесь строить дом, я сомневаюсь, что нужно придумывать собственный способ его постройки. Залить фундамент, на него поставить каркас, в каркасе провести коммуникации и сделать отделку.

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

Так вот, в программировании тоже все стандартные решения придумали за нас. Называются они паттерны, и вы уже слышали этот термин, когда обсуждали такие вещи как ООА\ООД\ООП.

В данный момент для нас с точки зрения создания веб-ресурсов самым важным из них является MVC (Model - View - Controller) (Модель - Отображение - Контроллер)

Что же это такое?

Это архитектурный паттерн.

А по сути это разделение обязанностей между тремя зависимыми блоками.

Ресторан

Давайте посмотрим на работу обычного ресторана.

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

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

Большая часть сайтов или приложений так же делится на три компонента, Model - View - Controller

Если рассматривать пример с рестораном, то зал, в котором находится клиент, его столик и его тарелка будут являться Отображением, оно же View, В случае с сайтом или приложением, этим элементом является всё что может увидеть пользователь.

Официант, который принимает заказ и выносит блюдо, является в этой аналогии http запросами и ответами. И общается только с Контроллером, он же Controller

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

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

При этом клиент не может заказать всё, что ему захочется, ему нужно будет выбрать из меню.

Сегодня мы изучим, как именно формируется меню для Django, и что это вообще.

По этому же принципу работает и Django, но с немного другими названиями, паттерн называется MVT (Model - View - Template)

  • View играет роль Controller
  • Template играет роль View

Но это точно такая же идея, изменились только названия блоков.

Что же такое все-таки Django?

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

Основной информационный ресурс Django

Наконец-то практика

Все что мы делаем, мы делаем со свежим, только что созданным, активированным ВИРТУАЛЬНЫМ ОКРУЖЕНИЕМ!!

Создадим новый проект

Для создания проекта создаём виртуальное окружение и активируем его (описание в прошлой лекции).

После чего необходимо выполнить два действия:

  • Установить Django
  • Перейти в папку, где мы собираемся создать проект, в котором будем писать код.

Порядок этих двух действий не имеет значения, ведь установка пакета Django через pip установит пакет в папку виртуального окружения, независимо от того, где вы находитесь.

Чтобы установить последнюю версию Django, необходимо выполнить команду:

pip install django

Если необходимо установить конкретную версию, нужно добавить ==x.y, например

pip install django==4.2

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

django-admin startproject mysite

mysite - это название вашего проекта, может быть таким, как вам необходимо.

Эта команда создаёт новый проект, и заполняет его базово нужными файлами, давайте рассмотрим их.

Структура файлов:

mysite /
    manage.py
    mysite /
        __init__.py
        settings.py
        urls.py
        wsgi.py
        asgi.py

manage.py - файл являющийся точкой входа, при помощи которого мы будем взаимодействовать со многими частями Django из консоли

Внутри папки mysite:

__init__.py - пустой файл, который говорит Python-у, что этот каталог должен рассматриваться как пакет Python-а

settings.py - настройки и конфигурации проекта.

urls.py - URL-ы для этого проекта; «меню» вашего сайта на платформе Django.

wsgi.py - файл, отвечающий за входную точку сервера (позволяет запускать код как сайт), разберём почти в самом конце курса

asgi.py - файл, отвечающий за входную точку сервера асинхронно (позволяет запускать код как сайт), разберём почти в самом конце курса

Проверим работоспособность.

В консоли запустим локальный "сервер" из папки с нашим "сайтом" (в моём примере mysite)

Если вы только что создали проект, то cd mysite.

Необходимо находиться в консоли в той же папке, где находится manage.py с включённым виртуальным окружением.

python manage.py runserver

Что произойдет в этой ситуации. Вы сообщили консоли, что ходите запустить python из виртуального окружения, через него запустить файл manage.py, с параметром runserver

В консоли должна появиться примерно такая надпись.

Эта команда запускает ваш сервер. И если вы хотите, что бы ваш сайт работал, сервер, должен быть запущен!

Не закрывая консоль (сервер должен работать), открываем в браузере http://127.0.0.1:8000/

А браузер будет клиентом (помним о взаимодействии клиент-сервер? )

При таком подходе наш компьютер сразу является и клиентом (браузер), и сервером (скрипт запущенный в консоли).

127.0.0.1 - это локальный хост (обращаться к вашему же собственному компьютеру),

а :8000 - это номер порта, на котором запущен процесс (если не указывать порт, то по умолчанию будет использоваться 80 порт для http и 443 для https).

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

127.0.0.1 можно заменить на 0.0.0.0 или слово localhost, все три варианта практически взаимозаменяемы.

Если вы всё сделали правильно, то в браузере должны увидеть, что-то такое:

Создаём приложение

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

Через консоль и уже известную нам manage.py создадим приложение

python manage.py startapp myapp

Команда создаст вам папку с вашим приложением, давайте разберем её подробнее.

mysite/
    ...
    myapp/
        __init__.py
        admin.py
        apps.py
        migrations/
            __init__.py
        models.py
        tests.py
        views.py

__init__.py - пустой файл, который говорит Python-у, что этот каталог должен рассматриваться как пакет Python-а

admin.py - заготовка под страницу для администратора, удобный встроенный инструмент, разберём на следующих занятиях

apps.py - информация о приложении, этот файл нам не мешает, как его можно использовать тоже сильно дальше расскажу.

папка migrations - тут будут миграции базы данных

models.py - модели

tests.py - тесты

views.py - контроллер приложения

Все эти файлы нам пока не известны, и на самом деле, пока даже не нужны. Если вы удалите все, кроме views.py, все будет работать точно так же. А views.py нам сегодня еще понадобится.

Что сегодня учим?

mvc_urls.png

URL

URL (Uniform Resource Locator) — это унифицированный указатель ресурса, который используется для идентификации и доступа к ресурсам в Интернете. URL указывает на адрес ресурса и способ его получения. URL состоит из нескольких частей, каждая из которых имеет свое предназначение.

Структура URL

Вот основные компоненты URL:

  1. Схема (Scheme):

    • Определяет протокол, используемый для доступа к ресурсу. Наиболее распространенные схемы включают http, https, ftp, mailto и другие.
    • Пример: https

    Мы будем практически до конца курса использовать только http

  2. Имя хоста (Hostname):

    • Указывает на доменное имя или IP-адрес сервера, на котором размещен ресурс.
    • Пример: www.example.com

    Мы будем использовать 127.0.0.1 тоже практически до конца

  3. Порт (Port) (необязательный):

    • Определяет порт, через который происходит соединение. Если порт не указан, используются порты по умолчанию для соответствующих схем (например, 80 для HTTP и 443 для HTTPS).
    • Пример: :443

    Мы будем использовать 8000 тоже практически до конца

  4. Путь (Path):

    • Указывает на конкретный ресурс на сервере, такой как файл или страница.
    • Пример: /path/to/resource

    Вот эта та часть которую мы сегодня и научимся программировать

  5. Запрос (Query) (необязательный):

    • Содержит дополнительные параметры, передаваемые на сервер. Запрос начинается с символа ?, и параметры разделяются символами &.
    • Пример: ?key1=value1&key2=value2

  6. Фрагмент (Fragment) (необязательный):

    • Указывает на часть ресурса, такую как якорь внутри страницы. Фрагмент начинается с символа #.
    • Пример: #section1

Пример полного URL

https://www.example.com:443/path/to/resource?key1=value1&key2=value2#section1

Использование URL

URL используется во многих контекстах:

  • Веб-браузеры используют URL для доступа к веб-страницам.
  • API используют URL для отправки запросов к веб-сервисам.
  • Программы и скрипты используют URL для загрузки файлов или доступа к удаленным ресурсам.

URL является важной частью Интернета, обеспечивая стандартизированный способ указания на ресурсы и взаимодействия с ними.

Наш первый URL

Теперь у нас всё готово для того, чтобы начать создавать наш сайт. Сегодня мы будем разбираться, как работают urls.

В рамках обучения мы будем запускать сервер через manage.py и описание работы будут для него же. На самом деле когда запускаются сервера, они этот файл не используют, но логика полностью сохраняется

manage.py

Если вы откроете файл manage.py то там вы увидите что-то такое:

#!/usr/bin/env python
"""Django's command-line utility for administrative tasks."""
import os
import sys


def main():
    """Run administrative tasks."""
    os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")
    try:
        from django.core.management import execute_from_command_line
    except ImportError as exc:
        raise ImportError(
            "Couldn't import Django. Are you sure it's installed and "
            "available on your PYTHONPATH environment variable? Did you "
            "forget to activate a virtual environment?"
        ) from exc
    execute_from_command_line(sys.argv)


if __name__ == "__main__":
    main()

Кстати обратите внимание и __main__, использование sys, os. Все как мы учили.

нас в данный момент интересует строчка:

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings")

Она сообщает всей системе, что в качестве настроек нужно использовать файл setting.py из папки mysite

Поэтому при любом запросе к запущенному Django приложению при обработке запроса запущенный сервер в первую очередь заходит в файл settings.py и ищет там переменную ROOT_URLCONF, по умолчанию там будет указан файл urls.py,который находится в той же папке, где и settings.py.

Внутри этого файла Django ожидает наличие переменной urlpatterns, которая содержит коллекцию (например, список), состоящую из специальных объектов path или re_path.

На самом деле эти объекты появились в Django только после версии, 2.0, сейчас актуальная версия это 5+, но потенциально вы можете встретить и версии ниже, например, 1.11, поэтому ниже мы разберем и более старые варианты урлов. До 2.0 там были коллекции из объектов url, и все они работали на регулярных выражениях, о них позже.

Вся основная логика обработки запросов пишется в приложениях в файлах views.py, у нас всего одно приложение, поэтому всю логику (сегодня она будет простейшая) мы будем писать в файл myapp/views.py.

Для начала изменим файл views.py

# mysite/myapp/views.py
from django.http import HttpResponse, HttpRequest


# Поздравляю, это ваш первый контроллер, который может принять запрос и отдать ответ с текстом, больше ничего
def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")

Мы создали функцию, которая принимает один параметр request типа HttpResponse и возвращает объект типа HttpResponse.

Это нужно, потому что вся веб-инфраструктура работает на request-response системе, мы тоже не будем её нарушать, и будем принимать запросы и возвращать ответы.

Объект HttpResponse мы импортировали из Django, и на данном этапе нас совершенно не интересует, как он работает, как и то, что именно находится в переменной request.

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

Для использования этого контроллера в качестве логики, он должен быть описан в файле urls.py:

# mysite/mysite/urls.py
from django.urls import path
from myapp.views import main

urlpatterns = [
    path('', main)
]

Мы импортировали path из Django и метод main из нашего views.py

Объект path принимает два обязательных параметра:

  • Строка, которая содержит путь
  • Обработчик, что именно должно происходить при запросе по такому пути.

Строка пути

Строка, которая указывает, как именно можно выполнить запрос к данному url.

Например, если указать там пустую строку и запустить сервер на локалхосте на 8000 порту, то запросы нужно выполнять по адресу 127.0.0.1:8000/

Если указать там, например, super_cool_path/, то обращаться нужно было бы к 127.0.0.1:8000/super_cool_path/

Не может содержать пробелов, может содержать /

Обработчик

Что угодно, что можно вызвать (), на данном этапе это функции, дальше мы будем использовать классы. При вызове добавляем в качестве аргумента переменную request.

Объект path так же может принимать атрибут name=, который нужен дня автоматической генерации адресов, будем изучать на следующем занятии, и некоторые другие необязательные атрибуты.

Если мы перезапустим (ну или запустим) сервер и откроем страницу, то мы увидим, что-то такое:

Список урлов проекта называется routing (маршрутизация). Маршрутизацию можно строить так, как вам удобно, или как того требует задание.

Напишем еще один контроллер, для "другой" страницы. В файле myapp/views.py

from django.http import HttpResponse, HttpRequest


def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")


def another(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's another page!!")

А в файле mysite/urls.py импортируем эти функции и добавим маршрут в список, чтобы получилось так:

from django.urls import path
from myapp.views import main, another

urlpatterns = [
    path('', main),
    path('some_url/', another)
]

То, что написано в строке до контроллера - это путь к урлу, а значит, чтобы увидеть обработку этого контроллера, нужно открыть страницу http:/127.0.0.1:8000/some_url/

Открываем эту страницу и видим результат:

Урлы с параметрами

Урл может заведомо принимать параметры, самый простой способ - это описание параметра через синтаксис <type:variable>

Обновим наш urls.py:

from django.urls import path
from myapp.views import main, another, main_article, uniq_article, article

urlpatterns = [
    path('', main),
    path('some_url/', another),
    path('article/', main_article, name='main_article'),
    path('article/33/', uniq_article, name='unique_article'),
    path('article/<int:article_id>/', article, name='article'),
]

Обратите внимание, часть урлов теперь имеет параметр name, он понадобится на следующем занятии.

А в последнем url мы указали параметр <int:article_id>, значение до двоеточия - это тип данных, принимаемых параметром, а после двоеточия - это имя параметра, который можно будет использовать в контроллере, чтобы получить значение этого параметра.

Всего существует 5 таких типов:

  • str - ищет непустую строку, без символа /

  • int - ноль или любое положительное число.

  • slug - по сути, это тоже строка, которая состоит из букв, цифр, нижних подчеркиваний, дефисов, символов плюс, например, building-your-1st-django-site отличается от обычной строки тем, что обычно этот урл берет данные из уже существующих данных. Слагом может быть название статьи, уникальный номер товара и т. д.

  • uuid - ищет соответствие UUID, это специальный формат, состоящий из шестнадцатеричных цифр, букв и дефисов, дефисы должны быть обязательно, буквы в нижнем регистре. Например, 075194d3-6885-417e-a8a8-6c931e272f00.

  • path - строка с одним или несколькими символами /

Обратите внимание, что url article/33/ попадает так же и под article/<int:article_id>/, потому что 33 - это тоже цифра, в этом случае будет использован тот, который находится в списке первым. Урлы считываются сверху вниз

Изменим myapp/views.py:

from django.http import HttpResponse, HttpRequest


def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")


def another(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's another page!!")


def main_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('There will be a list with articles')


def uniq_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('This is a unique answer for a unique value')


def article(request: HttpRequest, article_id: int) -> HttpResponse:
    return HttpResponse(f"This is article #{article_id}.")

Обратите внимание, в функцию article я добавил параметр article_id для получения значения в контроллере.

Давайте посмотрим на результат при переходе на разные страницы.

Последнее - это пример работы, если url не был описан (всем известная страница 404, в debug режиме она может рассказать много подробностей об ошибке). В данном примере ошибка говорит о том, что контроллера для указанного запроса не существует.

Так как параметры в функции могут быть не обязательными, мы можем воспользоваться и этим свойством тоже.

views.py

from django.http import HttpResponse, HttpRequest


def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")


def another(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's another page!!")


def main_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('There will be a list with articles')


def uniq_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('This is a unique answer for a unique value')


def article(request: HttpRequest, article_id: int, name: str = '') -> HttpResponse:
    return HttpResponse(
        "This is an article #{}. {}".format(article_id, "Name of this article is {}".format(
            name) if name else "This is unnamed article"))

urls.py

from django.urls import path
from myapp.views import main, another, main_article, uniq_article, article

urlpatterns = [
    path('', main),
    path('some_url/', another),
    path('article/', main_article, name='main_article'),
    path('article/33/', uniq_article, name='unique_article'),
    path('article/<int:article_id>/', article, name='article'),
    path('article/<int:article_id>/<slug:name>', article, name='article_name'),
]

Результаты некоторых запросов:

include

На самом деле path может принимать не только обработчик, но и специальный параметр include, который позволяет добавить urls из другого файла к основному.

Например, вы видите, что у нас есть 4 урла, которые начинаются на article/, а значит, что удобным вариантом было бы вынести urls в отдельный файл. Обычно такие файлы создаются на уровне приложений, а основной файл с urls содержит только команды include.

Чтобы перенести часть urls, нам необходимо создать файл urls.py в приложении myapp (на самом деле мы могли и назвать его как угодно, и сложить его куда угодно, но так просто удобнее и читаемее), и обязательно в этом файле создать переменную urlpatterns, содержащую коллекцию url.

Посмотрим на измененные и добавленные файлы:

myapp/urls.py

from django.urls import path
from .views import main_article, uniq_article, article

urlpatterns = [
    path('', main_article, name='main_article'),
    path('33/', uniq_article, name='unique_article'),
    path('<int:article_id>/', article, name='article'),
    path('<int:article_id>/<slug:name>', article, name='article_name'),
]

mysite/urls.py

from django.urls import path, include
from myapp.views import main, another

urlpatterns = [
    path('', main),
    path('some_url/', another),
    path('article/', include('myapp.urls'))
]

После этого изменения ни один url не изменился - они просто стали по другому располагаться

В случае с 4 urls не до конца понятно, зачем это может быть нужно, но когда у нас существует 20 приложений и в них 5000+ url, структура становится очень важна, чтобы ничего не потерять. Поэтому правилом хорошего тона для Django кода считается создание файла с urls в каждом приложении, а в основном файле хранить только команды include на них. (Если сделать url path('', include('app.urls')), то можно перенести и те 2 url, которые мы сейчас оставили в основных url.)

re_path

Регулярные выражения

Как говорит нам википедия Регуля́рные выраже́ния ( англ. regular expressions) — это используемый в компьютерных программах, работающих с текстом, формальный язык поиска и осуществления манипуляций с подстроками в тексте, основанный на использовании метасимволов (символов-джокеров, англ. wildcard characters). Для поиска используется строка-образец (англ. pattern, по-русски её часто называют «шаблоном», «маской»), состоящая из символов и метасимволов и задающая правило поиска. Для манипуляций с текстом дополнительно задаётся строка замены, которая также может содержать в себе специальные символы.

По факту это механизм, который позволяет понять, соответствует ли наша строка заданному шаблону.

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

Предположим, что нам нужно указать в качестве части урла три цифры и хотя бы 2 буквы (123blabla, 432fo,111aaaaa и т. д., но 12asd не подходило)

Чтобы собрать такую конструкцию, нужно воспользоваться синтаксисом регулярных выражений, мне лично нравится вот этот сайт, на нем можно изучить базовые принципы использования регулярных выражений.

Получаем необходимое регулярное выражение:

Теперь давайте попробуем использовать его в url

mysite/urls.py:

from django.urls import path, include, re_path
from myapp.views import main, another, regex

urlpatterns = [
    path('', main),
    path('some_url/', another),
    path('article/', include('myapp.urls')),
    re_path('\d{3}[a-zA-Z]{2,}', regex),
]

views.py

from django.http import HttpResponse, HttpRequest


def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")


def another(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's another page!!")


def main_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('There will be a list with articles')


def uniq_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('This is a unique answer for a unique value')


def article(request: HttpRequest, article_id: int, name: str = '') -> HttpResponse:
    return HttpResponse(
        "This is an article #{}. {}".format(article_id, "Name of this article is {}".format(
            name) if name else "This is unnamed article"))


def regex(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's regexp")

Обратите внимание, мы используем не path, a re_path.

Такой url уже будет работать.

Но как нам получить значение именно этого регулярного выражения? Как бы не было ужасно, но завернуть его в другое регулярное выражение.

И после этого не забыть получить его в контроллере.

mysite/urls.py

from django.urls import path, include, re_path
from myapp.views import main, another, regex

urlpatterns = [
    path('', main),
    path('some_url/', another),
    path('article/', include('myapp.urls')),
    re_path(r'^(?P<text>\d{3}[a-zA-Z]{2,}$)', regex),
]

views.py

from django.http import HttpResponse, HttpRequest


def main(request: HttpRequest) -> HttpResponse:
    return HttpResponse("Hey! It's your main view!!")


def another(request: HttpRequest) -> HttpResponse:
    return HttpResponse("It's another page!!")


def main_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('There will be a list with articles')


def uniq_article(request: HttpRequest) -> HttpResponse:
    return HttpResponse('This is a unique answer for a unique value')


def article(request: HttpRequest, article_id: int, name: str = '') -> HttpResponse:
    return HttpResponse(
        "This is an article #{}. {}".format(article_id, "Name of this article is {}".format(
            name) if name else "This is unnamed article"))


def regex(request: HttpRequest, text: str) -> HttpResponse:
    return HttpResponse(f"It's regexp with text: {text}")

Мы получили данные из урла.

Бывают и более сложные конструкции, рассмотрите их по вот этой ссылке

На практике редко встречаются более сложные конструкции, но Django представляет нам такую возможность.