outsider_x

Сделал расширение.
Google
Firefox

Можно, но если тебе потребуется реализовать связь m2m (например, принадлежность постов нескольким группам), то тебе придется в таблице-связке этот слаг дублировать. Не знаю, насколько это удобно, ведь слаг может меняться вообще - и придется его менять в нескольких таблицах. Или, скажем, тебе потребуется хранить в отдельной таблице "лайки" постов. В одном случае там у тебя будет post_id, на которое будет повешен внешний ключ на поле id (pk) в таблице с постами, а в другом тебе придется опять slug прописывать. По памяти, если что, varchar больше места занимает, чем int, индексы для таких столбцов, соответственно, тоже.

Тем более, если ты в этой же таблице будешь хранить историю изменений, то тебе придется slug дублировать. Так что primay_key=True внезапно уже бы не годилось на этом поле.

https://vk.com/catalog.php

Такие стандарты существуют. Наиболее известные - MISRA C и MISRA C++. Как можно догадаться, для языков С и С++, соответственно. Изначально созданы для автомобильной промышленности, но распространились и на аэрокосмическую отрасль, медицинскую технику, военных и прочие критичные к надёжности области. В том числе и АЭС.

Из MISRA C выросли SEI CERT C/C++, AUTOSAR General Software Specification, JPL Institutional Coding Standard for the C (стандарт NASA) и ещё куча других.

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

Помимо этого, существует ворох стандартов, описывающих подходы к организации процесса разработки и контроля качества. У каждой отрасли свои стандарты. Например, AS9100.

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

Update 2019-12-30:
На хабре появилась интересная статья с кратким обзором MISRA.

0) В базовый, не в базовый (наследующий базовый), это не важно. Важно то, как именно передать в шаблон. В базовый шаблон никакой контекст не передаётся. Базовый шаблон просто расширяет ваш шаблон, а контект там один.

1) В вашем случае НЕОБХОДИМО использовать штатный request.user и не парить себе мозг (https://docs.djangoproject.com/en/2.2/ref/request-...
Будет что-то типа {{ request.user.profile.get_absolute_url }}

UPD: Я не сразу углядел. У вас отедльная моделька для профиля, привязанная к пользователю.
Надо сделать в модели свойство, которое будет отдавать профиль для этого пользователя. Если сможете, то вопрос решен и будет работать как в примере выше. Если нет, то проще всего добавить context processor и отдавать переменную profile. Работать будет как-то так: {{ profile.get_absolute_url }}. Но лучше всего, конечно, определить в модели User свойство profile.

2) Если штатный request.user не подходит (почему!?), или вы хотите понять принцип на будущее, то есть два похожих варианта:
2.1) Передавать ваш объект в контекст конкретного шаблона из вьюхи. Будет работать только в этой вьюхе. Банально, да?
2.2) Написать context processor и добавить его в settings.TEMPLATES.OPTIONS.context_processors (см то, как это сделано в базовом settings.py и гугли примеры). Будет работать вообще везде в рамках рендера шаблонов. Мы не ищем лёгких путей для request.user!

Вадим Шаталов предлагает использовать фильтры/тэги. Это не совсем то (не совсем об этом), потому что в них всё равно надо будет или передавать request.user, или брать из контекста, куда его надо будет помещать одним из вышеописанных способов, или как-то его нечеловеческим образом откуда-то доставать, чего делать уже совсем не нужно.