Выход из командной строки python
обычно при вводе exit , вы хотели бы выйти из программы. Почему интерпретатор дает мне вышеуказанную ошибку, когда он знает, что я пытаюсь выйти из командной строки? Почему он просто не уходит? Я знаю, что это не имеет значения, и это глупый вопрос, но мне любопытно.
10 ответов
при вводе exit в командной строке, он находит переменную с таким именем и называет __repr__ (или __str__ ) на нем. Обычно, вы получите результат, как:
но они решили переопределить эту функцию для exit объект для отображения полезного сообщения. Является ли это глупым поведением или нет, это субъективный вопрос, но одна из возможных причин, почему он не «просто выходит»:
Предположим, вы смотрите на какой-то код в отладчике, для экземпляр, и один из объектов ссылается на
Это работает для меня, лучший способ выйти из подсказки python.
Я рекомендую вам выйти из интерпретатора Python с помощью Ctrl-D. Это старый код ASCII для конца файла или конца передачи.
это сообщение на exit
посмотрите на эти примеры :
поскольку интерпретатор не является оболочкой, в которой вы предоставляете команды, это — ну-интерпретатор. То, что вы ему даете, — это код Python.
синтаксис Python таков, что exit само по себе не может быть никем иным, кроме названия объекта. Просто ссылка на объект не может ничего сделать (кроме того, что обычно делает цикл read-eval-print; т. е. отображать строковое представление объекта).
в моем интерпретаторе python exit на самом деле строка, а не функция — ‘Use Ctrl-D (i.e. EOF) to exit.’ . Вы можете проверить своего переводчика, введя type(exit)
в активном python происходит то, что exit является функцией. Если вы не вызовете функцию, она распечатает строковое представление объекта. Это поведение по умолчанию для любого возвращаемого объекта. Просто дизайнеры подумали, что люди могут попытаться ввести exit для выхода из интерпретатора, поэтому они сделали строку представление функции exit полезное сообщение. Вы можете проверить это поведение, введя str(exit) или даже print exit .
вы можете это исправить.
ссылке PYTHONSTARTUP в файл python со следующим
как это работает?
командная строка python-это цикл чтения-оценки-печати, то есть при вводе текста он будет читать этот текст, оценивать его и в конечном итоге печатать результат.
при вводе exit() он оценивает вызываемый объект типа site.Quitter и называет его __call__ функция, которая выходит из системы. Когда вы печатаете exit он оценивает тот же вызываемый объект, не вызывая его, объект печатается, который в свою очередь вызывает __repr__ на объект.
мы можем воспользоваться этим путем связывания __repr__ to __call__ и таким образом получить ожидаемое поведение выхода из sustem, даже когда мы вводим exit без скобок.
на выезд из терминал Python, просто:
Пожалуйста, обратите внимание, что это функция, которая называется, как большинство пользователей смешать его с выходом без вызова, но новый Pyhton терминал показать сообщение.
или в качестве ярлыка нажмите:
Если вы застряли в командной строке python, и ни одно из вышеперечисленных решений не сработало для вас, попробуй!—0—>
«exit» — это допустимое имя переменной, которое может использоваться в вашей программе Python. Вы не захотите выходить из интерпретатора, когда вы просто пытаетесь увидеть значение этой переменной.
Шпаргалка по Python для Django
В Python очень много полезных функций, библиотек и других элементов, перечислить которые в одном материале очень сложно. Мы поделимся базовой шпаргалкой по Python, которая ориентирована на создание веб-приложений с фреймворком Django. Сохраняйте статью в закладки, чтобы не потерять!
Этот набор инструкций напомнит вам об основных операциях с Django, если вы работаете над веб-проектом. Сюда входят такие действия, как установка Django, запуск проекта, работа с моделями, создание домашней страницы, использование шаблонов и создание учётных записей пользователей.
Шпаргалка предназначена для тех, кто уже знаком с Python, понимает, что такое виртуальное окружение, и имеет начальные знания о веб-разработке.
Что такое Django?
Django — веб-фреймворк для создания интерактивных веб-сайтов на Python. В Django вы определяете тип данных, с которыми ваш сайт должен работать, а затем указываете, как пользователи могут взаимодействовать с этими данными. Все описанные ниже действия актуальны для Django 3.0.
Установка Django
Лучше установить Django в виртуальном окружении — virtualenv или pipenv, где ваш проект будет изолирован от других. Большинство команд, приведённых ниже, предполагают, что вы работаете в виртуальной среде.
Создать виртуальную среду
pipenv:
Активировать среду
venv, macOS and Linux:
venv, Windows:
pipenv:
Установить Django в активную среду
pipenv:
Создание проекта
Чтобы начать работу, мы создадим новый проект и базу данных, а затем запустим веб-сервер. Во всех примерах ниже проект будет называться learning_log .
Создать новый проект
Создать базу данных
Посмотреть проект
После выполнения этой команды вы можете просмотреть проект по адресу http://localhost:8000/.
Создать новое приложение
Проект Django состоит из одного или нескольких приложений.
Перезапуск сервера разработки
Если вы вносите изменения в свой проект, но ничего не происходит, попробуйте перезапустить сервер:
Работа с моделями
Данные в проекте Django представлены в виде набора моделей — объектов Python, определяющих структуру хранения этих данных.
Определение модели
Чтобы определить модель для вашего приложения, измените файл models.py , созданный в папке приложения. Метод __str __() сообщает Python, как отображать экземпляр модели в строковом представлении. Django использует этот механизм для отображения объектов в формах.
Активация модели
Для использования модели приложение должно быть добавлено в список INSTALLED_APPS , который хранится в файле settings.py проекта.
Миграция базы данных
База данных должна быть модифицирована для хранения данных модели. Вам нужно будет запускать эти команды каждый раз, когда вы создаете новую модель или модифицируете существующую модель.
Создание суперпользователя
Суперпользователь — это учётная запись с доступом ко всем компонентам проекта.
Регистрация модели
Вы можете зарегистрировать свою модель в панели администратора Django, чтобы упростить работу с данными в проекте. Для этого измените файл admin.py. Панель администратора находится по адресу http://localhost:8000/admin/.
Создание новой модели
Новая модель может использовать существующую модель. Атрибут ForeignKey устанавливает связь между экземплярами двух связанных моделей. Обязательно мигрируйте базу данных после добавления новой модели в ваше приложение.
Определение модели с внешним ключом:
Создание простой домашней страницы
Пользователи взаимодействуют с проектом через веб-страницы. Мы создадим простую домашнюю страницу без данных. Любой странице обычно нужен URL, представление (view) и шаблон (template). Представление — функция Python, которая принимает HTML-запрос и возвращает ответ на него. Шаблон — специальный набор инструкций, позволяющий динамически генерировать HTML.
Сопоставление URL-адресов проекта
Основной файл проекта urls.py сообщает Django, где найти файлы urls.py , связанные с каждым приложением в проекте.
Сопоставление URL-адресов приложения
Файл urls.py в приложении сообщает Django, какое представление использовать для каждого URL-адреса в этом приложении. Вам нужно создать этот файл самостоятельно и сохранить его в папке приложения.
Создание простого представления
Представление берёт информацию из запроса и отправляет данные в браузер, часто через шаблон. Функции представления хранятся в файле views.py . Ниже приведена простая функция, которая не извлекает какие-либо данные, но использует для отображения домашней страницы шаблон .
Написание простого шаблона
Шаблон устанавливает структуру страницы. Создайте папку с именем templates в директории проекта. Внутри templates создайте ещё одну папку с тем же именем, как у приложения. Здесь должны быть сохранены все файлы шаблонов. Шаблон домашней страницы будет сохранён как learning_logs/templates/learning_logs/ .
Наследование шаблонов
Многие элементы повторяются на каждой странице сайта или же в одном из разделов. Написав один родительский шаблон для сайта или раздела, вы можете легко установить внешний вид всего сайта.
Родительский шаблон
Родительский шаблон определяет общие элементы для набора страниц, а также уникальные блоки для отдельных страниц.
Дочерний шаблон
Дочерний шаблон использует тег для извлечения структуры родительского шаблона. Затем он переопределяет содержимое для блоков, указанных в родительском шаблоне.
Отступы в шаблоне
Отступы в Python обычно отбиваются четырьмя пробелами. В шаблонах вы часто можете встретить отступы в два пробела, потому что вложенность кода как правило более глубокая.
Создание страницы с данными
Большинство страниц в проекте должны показывать данные, относящиеся к текущему пользователю.
Параметры URL
URL-адрес часто принимает параметр, сообщающий ему, к каким данным из базы данных обращаться. Показанный ниже шаблон URL ищет идентификатор конкретной темы и присваивает его параметру topic_id .
Использование данных в представлении
Представление использует параметр из URL, чтобы извлечь правильные данные из базы данных. В этом примере представление отправляет контекстный словарь в шаблон, содержащий данные, которые должны отображаться на странице. Вы можете импортировать любую модель, которую используете.
Использование данных в шаблоне
Данные, передаваемые в словаре-контексте, доступны в шаблоне. Доступ к этим данным осуществляется с помощью переменных шаблона, которые обозначены двойными фигурными скобками. Вертикальная линия после шаблонной переменной указывает на фильтр. В нашем примере фильтр с именем date форматирует объекты даты, а фильтр разрыва строки правильно отображает абзацы на веб-странице.
Django Shell
Вы можете работать с проектом Django из командной строки. Это полезно для выполнения запросов и тестирования фрагментов кода.
Начать сеанс оболочки
Доступ к данным из проекта
Пользователи и формы
Большинство веб-приложений позволяют посетителям создавать учётные записи. Это позволяет пользователям работать с собственными данными. Некоторые из этих данных могут быть конфиденциальными, а некоторые — общедоступными. Формы Django позволяют пользователям вводить и изменять свои данные.
Учётные записи пользователей
Учётные записи пользователей можно обрабатывать приложением — ниже оно создаётся под названием users . Пользователи должны иметь возможность зарегистрироваться, войти и выйти из аккаунта. Django автоматизирует большую часть этих действий.
Создание приложения users
После создания приложения обязательно добавьте его в INSTALLED_APPS в файле settings.py проекта.
Добавление URL-адресов приложения users
Добавьте эти строки в файл urls.py проекта, чтобы включить в проект URL-адреса приложения users .
Использование форм в Django
Существует несколько способов создания форм и работы с ними. Вы можете использовать установки Django по умолчанию или настроить свои формы. Наиболее простой способ настроить ввод данных, основанных на ваших моделях — использование класса ModelForm. ModelForm автоматически создаёт форму на основе полей модели.
Создание URL для входа, выхода и регистрации
Пользователи смогут войти, выйти и зарегистрироваться на сайте. Создайте новый файл urls.py в папке приложения users .
Шаблон входа
Вид входа в систему предоставляется по умолчанию, но вам необходимо указать свой собственный шаблон входа. В примере ниже шаблон отображает простую форму входа и показывает основные сообщения об ошибках. Создайте папку templates в директории приложения users , а внутри templates — папку registration . Сохраните файл как login.html .
Тег помогает предотвратить CSRF-атаки с помощью форм. Элемент <
Отображение текущего статуса входа
Вы можете изменить шаблон base.html , чтобы показать, вошёл ли пользователь на сайт в данный момент, и предоставить ссылку на страницы входа и выхода. Django делает объект user доступным для каждого шаблона.
Тег user.is_authenticated позволяет вам показать конкретный контент пользователям в зависимости от того, вошли они в систему или нет. Свойство <
Шаблон logged_out
Выход из системы по умолчанию отображается с помощью шаблона logged_out.html , который необходимо сохранить в папке users/templates/registration .
Регистрация пользователей
Представление для регистрации должно отображать пустую форму регистрации при первом запросе страницы, а затем обработать заполненные поля. Успешная регистрация сохраняет данные пользователя, и затем выполняется вход в систему и перенаправление на домашнюю страницу.
Шаблон регистрации
Шаблон register.html отображает поля формы регистрации в виде списка тегов <p> .
Данные пользователей
У всех пользователей есть данные, которые относятся только к ним. Любая модель, подключенная напрямую к пользователю, нуждается в поле, связывающем экземпляры модели с конкретным пользователем.
Создание темы, принадлежащей пользователю
Чтобы связать данные с пользователем, импортируйте модель User и добавьте её в качестве внешнего ключа в модель данных.
После изменения модели вам нужно будет мигрировать базу данных и установить user ID для каждого существующего пользователя.
Запрос данных для текущего пользователя
Объект запроса имеет атрибут user в своём представлении. Вы можете использовать этот атрибут для получения данных пользователя — их извлекает метод filter() .
Ограничение доступа незарегистрированным пользователям
Некоторые страницы показываются только зарегистрированным пользователям. Представления для этих страниц могут быть защищены декоратором @login_required . Любое такое представление будет автоматически перенаправлять незарегистрированных пользователей на соответствующую страницу. Вот пример файла views.py :
Установка URL перенаправления
Декоратор @login_required отправляет неавторизованных пользователей на страницу входа. Добавьте следующую строку в файл settings.py , чтобы Django знал, как найти страницу входа.
Предотвращение случайного доступа
Некоторые страницы отображают данные на основе параметров URL. Вы можете проверить, что текущий пользователь имеет права на просмотр текущих данных, и вернуть ошибку 404, если это не так.
Формы для редактирования данных
С Django можно создать форму с существующими данными пользователя и возможностью изменять и сохранять их.
Создание формы с исходными данными
Параметр instance позволяет указать начальные данные для формы.
Изменение данных перед сохранением
Аргумент commit = False позволяет вносить изменения перед записью в базу данных.
Django — отличный фреймворк, и мы привели лишь малую часть базовых операций в нём. Если вы хотите поэкспериментировать с Django на настоящем сервере — попробуйте наши Облачные VPS с готовым шаблоном Django и почасовой оплатой от 37 копеек. После заказа сервера Django будет готов к работе уже через минуту.
Пишите в комментариях, шпаргалки по каким языкам или фреймворкам вы хотели бы видеть в нашем блоге.
django-admin.py и manage.py¶
django-admin.py – это консольный инструмент Django. Этот раздел описывает его возможности.
Также для каждого проекта автоматически создается manage.py . manage.py – это простой интерфейс для django-admin.py , который выполняет две вещи перед тем, как обратиться к django-admin.py :
Добавляет пакет проекта в sys.path .
Устанавливает переменную окружения DJANGO_SETTINGS_MODULE , чтобы она указывала на файл settings.py проекта.
Вызывает django.setup() для инициализации Django.
django.setup() отсутствовала в предыдущих версиях Django.
Если вы установили Django через setup.py , скрипт django-admin.py уже должен находиться в путях поиска(переменная окружения PATH ) вашей системы. Если система не может его найти, поищите его в подкаталоге site-packages/django/bin каталога установленного Python. Вы можете создать симлинк на скрипт в каталоге, который находится в путях поиска системы, например /usr/local/bin .
Пользователи Windows, где нет симлинков, могут скопировать django-admin.py в каталог, который уже находится в путях поиска системы, или отредактировать переменную окружения PATH (можно найти через Settings - Control Panel - System - Advanced - Environment. ) и добавить каталог с установленным django-admin.py .
При работе с одним проектом Django удобнее использоваться manage.py , чем django-admin.py . Если вам необходимо переключаться между различными фалами настройки, используйте django-admin.py с переменной окружения DJANGO_SETTINGS_MODULE или опцией --settings .
Во всех примерах в этом разделе используется django-admin.py , но вы можете использовать и manage.py , ничего не изменится.
Использование¶
command – одна из команд, описанных в этом разделе. options – необязательные опции команды.
Как отобразить помощь¶
Выполните django-admin.py help , что бы увидеть помощь и список доступных команд.
Выполните django-admin.py help --commands , чтобы увидеть список доступных команд.
Выполните django-admin.py help <command> , чтобы увидеть описание указанной команды и список доступных опций.
Названия приложений¶
Большая часть команд принимает список “названий приложений”. “Название приложения” – это название основного пакета приложения. Например, если настройка INSTALLED_APPS содержит строку 'mysite.blog' , название приложения будет blog .
Получаем текущую версию Django¶
Выполните django-admin.py version , чтобы получить текущую версию Django.
Вывод соответствует формату, описанному в PEP 386:
Вывод отладочной информации¶
Укажите --verbosity , чтобы определить уровень выводимых в консоль django-admin.py уведомлений и отладочной информации. Подробности смотрите в описании опции --verbosity .
Доступные команды¶
check <appname appname . >¶
Использует приложение проверки, чтобы проанализировать проект Django на наличие распространенных проблем.
Приложение проверки проекта проверит модели на наличие ошибок, также проверить инициализацию интерфейса администратора. Также предоставит предупреждения о проблемах совместимости, которые могут возникнуть при обновлении Django. Вы можете создать свои функции проверки.
По умолчанию проверяются все приложения. Вы можете указать список приложений в аргументах команды:
Если приложения не указаны, будут проверены все установленные приложения.
Приложение проверки выполняет большое количество различных типов проверок. Это типы определяются тегами. Вы можете указать список тегов, чтобы ограничить выполняемые проверки. Например, чтобы проверить проект только на безопасность и совместимость, выполните:
Выводит список всех доступных тегов.
compilemessages¶
Компилирует .po файлы, созданные командой makemessages , в файлы .mo, которые используются gettext для локализации проекта. Смотрите Интернационализация и локализация.
Вы можете указать список локалей с помощью опции --locale (сокращенный вариант -l ). Если опция не указана, будут обработаны все локали.
Добавлена возможность указать несколько локалей.
createcachetable¶
Создает таблицу в базе данных, которая будет использоваться соответствующим бэкендом кеша. Смотрите Система кэширования Django.
Опция --database позволяет указать базу данных, в которой будет создана таблица.
Больше не обязательно указывать название таблицы или опцию --database . Django берет эту информацию из файла настроек. Если вы указали несколько кешей или баз данных, будут созданы все необходимые таблицы.
dbshell¶
Запускает консольный клиент для подключения к базе данных. Консольный клиент определяется настройкой ENGINE , параметры подключения – настройками USER , PASSWORD , и т.д.
Для PostgreSQL используется консольный клиент psql .
Для MySQL используется mysql .
Для SQLite используется sqlite3 .
Эта команда подразумевает, что клиент находится в PATH системы, и запуск клиента в консоли ( psql , mysql , sqlite3 ) работает. Нет способа указать путь к клиенту.
Опция --database позволяет указать базу данных, к которой будет выполнено подключение.
diffsettings¶
Показывает разницу между текущими настройками и настройками Django по умолчанию.
Настройки, которые не указаны в настройках по умолчанию, выводятся с "###" в конце. Например, в настройках по умолчанию не указан ROOT_URLCONF , и в выводе diffsettings , к ROOT_URLCONF будет добавлен "###" в конце.
Опция --all позволяет вывести все настройки, даже если они не отличаются от настроек по умолчанию. Такие настройки выводятся с префиксом "###" .
Была добавлена опция --all .
dumpdata <app_label app_label app_label.Model . >¶
Выводит в консоль все данные из базы данных, которые связаны с указанными приложениями.
Если приложение не указано, будет выполнен дамп данных для всех приложений.
Вывод команды dumpdata может использоваться для команды loaddata .
Обратите внимание, dumpdata использует менеджер по умолчанию модели для получения данных. Если вы используете собственный менеджер как менеджер по умолчанию, который отфильтровывает часть данных, отфильтрованные данные не попадут в результат команды.
Опция --all позволяет указать dumpdata использовать базовый менеджер Django, чтобы исключить фильтрацию данных собственным менеджером модели.
По умолчанию dumpdata будет выводить данные в формате JSON. Вы можете указать другой формат с помощью опции --format . Доступные форматы описаны в Serialization formats.
По умолчанию dumpdata выведет все данные одной строкой. Это не очень удобно для понимая человеком. Для читабельного вывода вы можете указать опцию --indent . Указанное значение будет использоваться как величина отступа.
Опция --exclude позволяет исключить определенные приложения или модели (формат значений – app_label.ModelName ). Если в аргументах dumpdata указать модель, будет выведен дамп данных только для этой модели, а не всего приложения. Вы можете указать модели и приложения вместе.
Опция --database позволяет указать базу данных, с которой будут загружаться данные.
Если указана эта опция, Django будут использовать метод связанной модели natural_key() для внешних ключей и связей многое-ко-многим. Если вы делаете дамп contrib.auth Permission или contrib.contenttypes ContentType , вам следует использовать эту опцию. Подробности смотрите в разделе о натуральных ключах.
Если указана эта опция, Django не будет добавлять первичный ключ в результат, т.к. он может быть вычислен при десирализации данных.
Не рекомендуется, начиная с версии 1.7: Аналог опции --natural-foreign , используйте её вместо этой опции.
Django будут использовать натуральные ключи для внешних ключей и связей многое-ко-многим.
По умолчанию dumpdata выведет все объекты модели, но вы можете использовать опцию --pks , чтобы указать через запятую список ID объектов, которые необходимо вывести. Эта опция доступна только при дампе одной модели.
flush¶
Удаляет все данные из базы данных, запускает “post-synchronization” обработчики и загружает начальные данные из фикстур.
Опция --noinput отключить вывод в консоль.
Опция --database позволяет указать базу данных, которая будет очищена.
--no-initial-data ¶
Опция --no-initial-data позволяет отключить загрузку начальных данных из “initial_data” фикстур.
inspectdb¶
Анализирует таблицы в базе данных, указанной настройкой NAME , и выводит сгенерированные модели Django.
Вы можете использовать эту команду, чтобы создать модели для уже существующей базы данных. Команда анализирует базу данных и создает модель для каждой таблицы.
Сгенерированные модели будут содержать атрибут поля для каждого поля таблицы. Обратите внимание, есть несколько особенностей в работе этой команды:
Если inspectdb не может подобрать подходящий тип поля модели, будет использоваться поле TextField с комментарием в коде 'This field type is a guess.' возле этого поля.
Если название колонки в таблице входит в зарезервированные слова Python (такие как 'pass' , 'class' или 'for' ), inspectdb добавит '_field' к названию атрибута. Например, если таблица содержит колонку 'for' , сгенерированная модель будет содержать поле 'for_field' , с параметром db_column равным 'for' . inspectdb добавит комментарий в коде 'Field renamed because it was a Python reserved word.' возле поля.
Эту команду можно использовать для генерации начальных моделей. После выполнения команды вам следует проверить сгенерированные модели и внести необходимые изменения. Также вам следует изменить порядок моделей в соответствии с внешними связями.
Первичные ключи автоматически определяются для PostgreSQL, MySQL и SQLite, и Django добавит для соответствующих полей primary_key=True .
inspectdb работает с PostgreSQL, MySQL и SQLite. Определение внешних ключей работает только для PostgreSQL и некоторых типов таблиц MySQL.
Django не добавляет значение по умолчанию для колонки в таблице, если поле модели содержит default . Аналогично команда inspectdb не добавляет в поле модели значение по умолчанию из колонки в таблице.
По умолчанию inspectdb создает неуправляемые модели. То есть с managed=False``в классе ``Meta модели, что указывает Django не управляет созданием, изменением или удалением таблицы. Чтобы позволить Django управлять моделью, установите параметр managed в True (или просто удалите его, True является значением по умолчанию).
Опция --database позволяет указать базу данных.
Созданные модели содержат managed=False с Django 1.6.
loaddata <fixture fixture . >¶
Ищет и загружает указанные фикстуры в базу данных.
Опция --database позволяет указать базу данных, в которую будут загружены данные..
Опция --ignorenonexistent позволяет игнорировать отсутствие полей в модели, если они были удалены после создания фикстуры.
Была добавлена опция --app .
Опция --app позволяет указать приложение, которое будет использоваться для поиска фикстур. Без этой опции фикстуры ищутся во всех приложениях.
Что такое “фикстура”?¶
Фикстура – это файл с сериализированными данными из базы данных. У каждой фикстуры уникальное название Фикстуры могут находиться в различных каталогах и приложениях.
Django ищет фикстуры в следующих местах:
В каталоге fixtures установленных приложений
В каталогах, указанных в настройке FIXTURE_DIRS
Путь, которые содержится в названии фикстуры
Django загрузит все фикстуры, которые найдет по указанному названию.
Если название фикстуры содержит расширение файла, только фикстуры этого типа будут загружены. Например:
загрузит только JSON фикстуры с названием mydata . Расширение фикстуры должно соответствовать одному из доступных сериалайзеров (например, json или xml ).
Если расширение не указано в названии фикстуры, Django будет искать фикстуры всех возможных типов. Например:
выполнит поиск фикстуры с названием mydata и с любым типом. Если каталог фикстур содержит mydata.json , этот файл будет загружен как JSON фикстура.
Название фикстуры может содержать относительный путь. Он будет использоваться при поиске фкистуры. Например:
выполнит поиск в <app_label>/fixtures/foo/bar/mydata.json в каждом установленном приложении, <dirname>/foo/bar/mydata.json – для каждого каталога из FIXTURE_DIRS , и foo/bar/mydata.json .
После обработки фикстур данные будут загружены непосредственно в базу данных. Метод save() модели не будет вызван. Обработчики сигналов pre_save и post_save будут вызваны с аргументом raw=True т.к. экземпляр модели содержит только локальные атрибуты. Вы можете, например, отключить обработчик, который обращается к внешним ключам т.к. они не определены при загрузке фикстуры, что вызовет исключение:
Также вы можете для этого создать простой декоратор:
Учитывайте, что этот код отключает обработку сигналов при любой загрузке фикстур, а не только для команды loaddata .
Обратите внимание, не известно в каком порядке будут загружены фикстуры. Но все данные будут добавлены в базу данных в одной транзакции, и данные из одной фикстуры могут ссылаться на данные из другой фикстуры. Если база данных содержит проверку внешних ключей, она будет выполнена в конце транзакции.
Для генерации фикстур для loaddata можно использовать команду dumpdata .
Сжатые фикстуры¶
Фикстуры могут быть сжаты в zip , gz или bz2 архив. Например:
будет искать mydata.json , mydata.json.zip , mydata.json.gz или mydata.json.bz2 . Первый файл из архива будет загружен как фикстура.
Обратите внимание, если найдено две фикстуры с одинаковым именем, но разного формата (например, mydata.json и mydata.xml.gz были найдены в одном каталоге), загрузка фикстур будет остановлена, и загруженные loaddata до этого данные будет удалены из базы данных.
MySQL с MyISAM и фикстуры
Хранилище MyISAM в MySQL не поддерживает транзакции и проверку внешних ключей. Если вы используйете MyISAM, проверка данных из фикстур не будет выполнена, как и откат изменений, если было найдено несколько фикстур с одинаковыми названиями.
Фикстуры для определенной базы данных¶
Если вы используете несколько баз данных, вам может понадобиться загрузить фикстуры в одну базу данных, но не загружать в другую. В таком случае вы можете добавить идентификатор базы данных в название фикстуры.
Например, если настройка DATABASES содержит базу данных ‘master’, назовите фикстуру mydata.master.json или mydata.master.json.gz и она будет загружена в базу данных master .
makemessages¶
Анализирует все файлы в текущем каталоге и парсит строки, которые помечены для перевода. Создает (или обновляет) файл переводимых сообщений в conf/locale (в каталоге проекта) или каталоге переводов (для проекта или приложения). Чтобы использовать файлы перевода с помощью gettext , необходимо их скомпилировать командой compilemessages . Смотрите раздел о i18n
Используйте опцию --all или -a чтобы обновить файлы перевода для всех языков.
С помощью опции --extension или -e можно указать список расширений файлов, которые будут обрабатываться командой (по умолчанию: ”.html”, ”.txt”).
Вы можете укать несколько расширений через запятую, или указав опцию -e или –extension несколько раз:
Опция --locale (или короткий вариант -l ) позволяет указать обрабатываемые локали.
Добавлена возможность указать несколько локалей.
Была добавлена опция --previous для команды msgmerge , которая используется для создания po файлов.
Опция --domain или -d позволяет изменить “домен” файлов перевода. Поддерживается:
django для *.py , *.html и *.txt файлов (по умолчанию)
Опция --symlinks или -s позволяет указать следовать ли по символическим ссылкам при поиске файлов.
Опция --ignore или -i позволяет игнорировать файлы или каталоги, которые соответствуют указанному шаблону в стиле glob . Можно указать несколько раз.
По умолчанию используются следующие шаблоны: 'CVS' , '.*' , '*
Опция --no-default-ignore позволяет отключить значения по умолчанию для --ignore .
Опция --no-wrap позволяет отключить разбивку длинных сообщений на несколько строк в файле перевода.
Опция --no-location позволяет отключить добавление ‘ #: filename:line ’ в файлы перевода. Обратите внимание, использование этой опции может усложнить работу технически образованным переводчикам, которым такие комментарии помогают понять смысл переводимого сообщения.
Опция --keep-pot указывает Django не удалять временные .pot файлы, которые создаются перед созданием .po файлов. Это полезно при отладке ошибок, которые мешают созданию файлов перевода.
makemigrations [<app_label>]¶
Создает новые миграции на основе изменений в моделях. Подробнее о миграциях вы можете прочитать в соответствующем разделе.
Вы можете указать приложения, для которых следует создать миграции, также будут учитываться связанные приложения (например, которые содержат модели, на которые ссылаются ForeignKey ).
Опция --noinput отключить вывод в консоль.
Опция --empty укажет makemigrations создать пустую миграцию для последующего редактирования вручную. Эту опцию следует использоваться только продвинутым пользователям, которые хорошо знают как работают миграции в Django.
Опция --dry-run позволяет вывести все действия, которые будут выполнять создаваемые миграции, не создавая файл с миграцией. Если дополнительно указать --verbosity 3 , будет выведено содержимое файлов миграций, которые будут созданы.
Опция --merge позволяет исправить конфликты в миграциях.
migrate [<app_label> [<migrationname>]]¶
Синхронизирует состояние базы данных с текущим состоянием моделей и миграций. Подробнее о миграциях вы можете прочитать в соответствующем разделе.
Поведение команды зависит от указанных аргументов:
Без аргументов: будет выполнена синхронизация всех приложений,
<app_label> : Будут выполнены миграции для указанного приложения до самой последней миграции. Это может вызвать миграцию других приложений через зависимости в миграциях.
<app_label> <migrationname> : Приводит состояние базы данных к состоянию, которые было бы после завершения указанной миграции. Обратите внимание, это может привести к отмене миграций, если были выполнены миграции, которые следуют после указанной вами. Используйте zero , чтобы отменить все миграции для приложения.
В отличии от syncdb эта команда не пытается создать супер-пользователя, если такой не существует (подразумевается, что вы используете django.contrib.auth ). Для этого используйте команду createsuperuser .
Опция --database позволяет указать базу данных для миграции.
Опция --fake указывает Django пометить миграции как выполненные/невыполненные без выполнения каких-либо SQL запросов.
Эта опция предназначена для опытных пользователей, которые хотят явно указать состояние миграций после применения изменений вручную. Будьте осторожны, использование --fake может “сломать” автоматическое применение миграций.
Опция --list выведет все приложения в проекте, список доступных миграций и пометки были ли они выполнены (знак [X] возле названия миграции).
Приложения без миграций также будут указаны, но с пометкой (no migrations) .
runfcgi [options]¶
Не рекомендуется, начиная с версии 1.7: Поддержка FastCGI устарела и будет удалена в Django 1.9.
Запускает несколько совместимых с FastCGI процессов, которые могут использоваться с Web-сервером, который поддерживает FastCGI протокол. Смотрите раздел о FastCGI. Требует FastCGI Python модуль из flup.
Внутри выполняет оборачивание объекта WSGI приложения, указанного в настройке WSGI_APPLICATION .
Доступные опции передаются в библиотеку FastCGI и не используют префикс '--' , как это принято для остальных команд Django.
Используемый протокол. PROTOCOL может быть fcgi , scgi , ajp и т.д.. (по умолчанию fcgi )
Доступные значения: prefork или threaded (по умолчанию prefork )
Количество запросов после которого будет перезапущен дочерний процесс (0 - неограниченное количество запрос).
Максимальное количество “запасных” процессов / потоков.
Минимальное количество “запасных” процессов / потоков.
Лимит на количество процессов / потоков.
“Отвязать” ли от терминала.
Записать ID процесса в файл FILE.
Переключиться на каталог DIRECTORY при создании процесса-демона.
Укажите true , чтобы включить полный трейсбек в flup.
Записывать stdout в файл FILE.
Записывать stderr в файл FILE.
Umask, которая будет использоваться при “демонизации” процесс. Значение должно быть восьмеричным числом (по умолчанию 0o22 ).
Запускает FastCGI сервер как демон и записывает PID в файл.
runserver [port или address:port]¶
Запускает простой локальный Web-сервер для разработки. По умолчанию сервер запускается на 8000 порте и 127.0.0.1 IP адресе. Вы можете явно указать IP адрес и порт.
Если вы запускаете команду как пользователь со стандартными правами (рекомендуется), у вас может не быть доступа к портам с малым номером. Такие порты зарезервированы для супер-пользователя (root).
Этот сервер использует объект WSGI приложения, которое указанно в настройке WSGI_APPLICATION .
НЕ ИСПОЛЬЗУЙТЕ ЭТОТ СЕРВЕР НА БОЕВОМ СЕРВЕРЕ. Этот сервер не анализировался на предмет уязвимостей и не подвергался тестам производительности. (И так оно и будет. Мы умеем делать Web-фреймворки, не Web-серверы, по этому доработка этого сервера не входит в наши задачи.)
Сервер для разработки автоматически перезапускается при изменении Python кода при необходимости. Нет необходимости перезапускать сервер при каждом изменении. Однако, некоторые изменения, такие как добавление файла, не вызывают перезапуск сервера, и вам необходимо сделать это самостоятельно.
Компилирование файлов перевода теперь перезапускает сервер для разработки.
Если вы используете Linux и установили pyinotify, будут использоваться kernel signals для перезапуска сервера (вместо мониторинга времени изменения файлов). Это улучшает производительность для больших проектов, уменьшает время реакции на изменения кода, более надежное обнаружение изменений, и уменьшает потребление заряда батареи.
Была добавлена поддержка pyinotify .
После запуска сервера при каждом изменении Python кода, сервер будет проверять весь Django проект на предмет ошибок (смотрите описание команды check ). Ошибки будут выведены в консоль, но сервер не будет остановлен.
Вы можете запустить несколько серверов, указав разные порты. Просто запустите django-admin.py runserver несколько раз.
Обратите внимание, IP адрес по умолчанию( 127.0.0.1 ) не доступен для других машин в вашей сети. Чтобы сервер был доступен в сети, укажите ваш IP (например 192.168.2.1 ) или 0.0.0.0 иди :: (если включен IPv6).
Вы можете указать IPv6 адрес в квадратных скобках (например [200a::1]:8000 ). Это включит поддержку IPv6.
Можно использовать имя хоста, которое состоит из ASCII-символов.
Если включено приложение staticfiles (по умолчанию включено в новых проектах), команда runserver будет заменена на команду runserver этого приложения.
Опция --noreload позволяет отключить автоматическую перезагрузку сервера при изменении Python файлов.
Сервер для разработки по умолчанию многопоточный. Опция --nothreading позволяет отключить многопоточность.
Опция --ipv6 (или короткий вариант -6 ) указывает Django использовать IPv6. IP адрес по умолчанию 127.0.0.1 будет заменен на ::1 .
Примеры использования различных портов и адресов¶
Порт 8000 по IP адресу 127.0.0.1 :
Порт 8000 по IP адресу 1.2.3.4 :
Порт 7000 по IP адресу 127.0.0.1 :
Порт 7000 по IP адресу 1.2.3.4 :
Порт 8000 по IPv6 адресу ::1 :
Порт 7000 по IPv6 адресу ::1 :
Порт 7000 по IPv6 адресу 2001:0db8:1234:5678::9 :
Порт 8000 по IPv4 адресу на хосте localhost :
Порт 8000 по IPv6 адресу на хосте localhost :
Раздача статических файлов сервером для разработки¶
По умолчанию сервер для разработки не раздает статические файлы (CSS файлы, изображения и другие файлы по адресу MEDIA_URL ). Как настроить раздачу файлов можно узнать из раздела Работа со статическими файлами (CSS, изображения).
shell¶
Запускает интерактивный интерпретатор Python.
Django использует IPython или bpython, если они установлены. Если вы хотите использовать “обычный” интерпретатор Python, укажите опцию --plain :
Если у вас установлен IPython и bpython, вы можете явно указать какой использовать с помощью опции -i или --interface :
При запуске “обычного” интерпретатора Python, он выполняет скрипт, указанный в переменной окружения PYTHONSTARTUP , а также скрипт
/.pythonrc.py . Опция --no-startup позволяет отключить такое поведение:
Опция --no-startup была добавлена в Django 1.6.
sql <app_label app_label . >¶
Выводит в консоль CREATE TABLE SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqlall <app_label app_label . >¶
Выводит в консоль CREATE TABLE и все инициализирующие SQL запросы для указанных приложений.
Смотрите описание sqlcustom , чтобы узнать как добавить загрузку начальных данных.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
Команды sql* теперь учитывают метод allow_migrate() объектов из настройки DATABASE_ROUTERS . Если у вас есть модели, которые синхронизированы не в базу данных по умолчанию, используйте опцию --database , чтобы получить SQL для этих моделей (ранее они всегда включались в вывод команды).
sqlclear <app_label app_label . >¶
Выводит в консоль DROP TABLE SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqlcustom <app_label app_label . >¶
Выводит в консоль собственные SQL запросы для указанных приложений.
Для каждой модели указанных приложений эта команда ищет файл <app_label>/sql/<modelname>.sql , где <app_label> — название приложения, а <modelname> — название модели в нижнем регистре. Например, для приложения news и модели Story , sqlcustom будет искать файл news/sql/story.sql и добавит его содержимое в результат выполнения команды.
Каждый найденный SQL файл должен содержать правильные SQL запросы. SQL файлы загружаются непосредственно в базу данных, сразу после создания таблиц для моделей. Используйте их, чтобы внести изменения в таблицу, или добавить SQL функции.
Обратите внимание, порядок, в котором загружаются SQL файлы, не определен.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqldropindexes <app_label app_label . >¶
Выводит в консоль DROP INDEX SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqlflush¶
Выводить в консоль SQL запросы, которые будут выполнены при выполнении команды flush .
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqlindexes <app_label app_label . >¶
Выводит в консоль CREATE INDEX SQL запросы для указанных приложений.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
sqlmigrate <app_label> <migrationname>¶
Выводит в консоль SQL запросы для указанной миграции. Требует активного подключения к базе данных, чтобы определить доступны имена constraint(FIXME). Это значит, что вы должны создать SQL для копии базы данных, к которой будут применяться запросы.
Обратите внимание, sqlmigrate не использует цветной вывод в консоль.
Опцию --database позволяет указать базу данных, для которой необходимо создать SQL запросы.
По умолчанию SQL создает для применения миграций. Опция --backwards позволяет создать SQL для отмены миграций.
sqlsequencereset <app_label app_label . >¶
Выводит в консоль SQL запросы для сброса счетчика автоинкрементных полей.
Эти счетчики используются для определения следующего доступного номера.
Вы можете использовать эту команду для генерации SQL запросов, которые помогут исправить несоответствие счетчиков и существующих данных в автоинкрементных полях.
Опция --database позволяет указать базу данных, для который выводить SQL запросы.
squashmigrations <app_label> <migration_name>¶
Объединяет миграции, если это возможно, для приложения app_label от начальной и до migration_name , включая её. Полученные объединенные миграции могут существовать параллельно с начальными. Подробности смотрите в разделе Объединение миграций.
По умолчанию Django пытается оптимизировать операции в миграциях, чтобы уменьшить размер файла. Опция --no-optimize позволяет отключить такое поведение, если оптимизация привела к созданию неправильной миграции, или ошибке при выполнении команды. Также мы просим сообщить об этом в баг-трекере Django.
startapp <app_label> [destination]¶
Создает структуру каталога приложения Django с указанным названием в текущем каталоге, или в котором вы укажите.
По умолчанию созданный каталог содержит файл models.py и другие файлы шаблона приложения. (Смотрите исходный код). Если вы указали только название приложения, оно будет создано в текущем каталоге.
Если вы указали путь к каталогу, Django будет использовать его, вместо создания нового. Вы можете использовать ‘.’, чтобы указать текущий каталог.
Опция --template позволяет указать путь к своему шаблону приложения. Вы можете указать путь к каталогу или архиву ( .tar.gz , .tar.bz2 , .tgz , .tbz , .zip ), который содержит файлы шаблона приложения.
Django также позволяет указать URL ( http , https , ftp ) к архиву с шаблоном приложения, он будет автоматически загружен и распакован.
Например, используя возможность Github-а предоставлять zip-архив с кодом репозитория, вы можете использовать следующий URL:
Когда Django копирует файлы, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py ), и файлы с названием, указанным опцией --name . При рендеринге используется template context со следующими переменными:
Все опции, переданные при вызове команды startapp (только поддерживаемые этой командой)
app_name – название приложение, указанное при вызове команды
app_directory – полный путь к созданному приложению
docs_version – версия документации: 'dev' или '1.x'
При рендеринге файлов шаблона приложения (по умолчанию все *.py файлы) Django заменит все шаблонные переменные. Например, если какой-то Python файл содержит комментарий, описывающий примеры использования системы шаблонов Django, он может быть искажен в созданном приложении.
Чтобы избежать этого, используйте тег templatetag для “экранирования” синтаксиса шаблонов.
startproject <projectname> [destination]¶
Создает структуру каталога проета Django с указанным названием в текущем каталоге, или в котором вы укажите.
По умолчанию новый каталог содержит manage.py и пакет проекта (содержащий settings.py и другие файлы). Подробности смотрите в исходниках.
Если указано только название проекта, и каталог и Python пакет проекта будет называться <projectname> , и будут созданы в текущем каталоге.
Если указать необязательный путь к каталогу, Django будет использовать его как каталог проекта, создаст в нём manage.py и пакет проекта. Можно использовать ‘.’, чтобы указать текущий каталог.
Как и для команды startapp , опция --template позволяет указать путь или URL к шаблону проекта. Подробности смотрите в описании startapp .
Например, следующая команда будет использоваться указанный шаблон для создания проекта myproject :
Django также принимает URL-ы ( http , https , ftp ) к архиву с шаблоном проекта, он будет автоматически загружен и распакован.
Например, используя возможность Github-а предоставлять zip-архив с кодом репозитория, вы можете использовать следующий URL:
Когда Django копирует файлы шаблона проекта, он может рендерить определенные файлы как шаблоны Django: все файлы с расширением, указанным опцией --extension (по умолчанию py ), и файлы с названием, указанным опцией --name . При рендеринге используется template context со следующими переменными:
Все опции, переданные при вызове команды startproject (только поддерживаемые этой командой)
project_name – название проекта, указанное при вызове команды
project_directory – полный путь к созданному проекту
secret_key – случайный ключ для настройки SECRET_KEY
docs_version – версия документации: 'dev' или '1.x'
syncdb¶
Не рекомендуется, начиная с версии 1.7: Эта команда устарела, используйте migrate , которая включает старые функции и выполнение миграций. Теперь это просто синоним новой команды.
test <app или test identifier>¶
Выполняет тесты для всех установленных моделей(FIXME: models?). Смотрите Тестирование в Django.
Опция --failfast позволяет остановить выполнение тестов после первой ошибки.
Опция --testrunner позволяет указать класс исполнителя тестов, который будет использоваться для запуска тестов. Указанное значение переопределяет значение настройки TEST_RUNNER .
Опция --liveserver позволяет переопределить адрес по умолчанию для тестового сервера (используется с LiveServerTestCase ). По умолчанию используется localhost:8081 .
testserver <fixture fixture . >¶
Запускает сервер Django для разработки (как и runserver ), используя данные из указанных фикстур.
Создаст тестовую базу данных, как описано вы Тестовая база данных.
Добавит в нее данных из указанных фикстур. (Подробности о фикстурах смотрите в описании loaddata .)
Запускает сервер Django для разработки (как и runserver ), сервер будет использовать созданную тестовую базу данных.
Эта команда может быть полезна в следующих случаях:
Когда вы пишете юнит тесты для представлений, вы можете использовать testserver , чтобы проверить работу страниц в браузере с тестовыми данными.
Предположим вы разрабатываете приложение и у вас есть “нетронутая” копия базы данных, с которой вы хотите работать. Вы можете сделать дамп базы в фикстуру (используя команду dumpdata ), затем запустить testserver с этими данными. С тестовым сервером вы можете как угодно менять данные, зная, что все изменения применяются к тестовой базе данных.
Обратите внимание, этот сервер не определяет изменения в Python файлах (как это делает команда runserver ). Однако, он отслеживает изменения в шаблонах.
--addrport [port number or ipaddr:port]¶
Опция --addrport позволяет указать порт, или IP и порт, переопределив значение по умолчанию 127.0.0.1:8000 . Формат значение аналогичен runserver .
Чтобы запустить тестовый сервер на 7000 порту с фикстурами fixture1 и fixture2 :
(Эти команды идентичны. Мы указали обе, чтобы показать, что порядок аргументов и опций не важен.)
Чтобы запустить сервер на 1.2.3.4:7000 с фикстурой test :
Опция --noinput отключить вывод в консоль.
validate¶
Не рекомендуется, начиная с версии 1.7: Заменена командой check .
Проверяет все установленные модели (в соответствии с настройкой INSTALLED_APPS ) и выводит ошибки валидации.
Команды предоставленные приложениями¶
Некоторые команды доступны только в случае, если приложение django.contrib , которое реализует их, было установлено . Этот раздел описывает эти команды, сгруппированные по приложениям.
django.contrib.auth ¶
changepassword¶
Эта команда работает только, если установлена система авторизации ( django.contrib.auth ).
Позволяет изменить пароль пользователя. Требует дважды ввести новый пароль для указанного пользователя. Если введённые пароли совпадают, новый пароль будет установлен. Если вы не указали пользователя, команда попытается найти пользователя с именем аналогичным текущему пользователю системы.
Опция --database позволяет указать базу данных, в которой следует искать пользователя. Если не указана, Django будет использовать default базу данных.
createsuperuser¶
Эта команда работает только, если установлена система авторизации ( django.contrib.auth ).
Создает суперпользователя (пользователь со всеми правами). Можно использовать для создания самого первого суперпользователя, или чтобы программно создавать суперпользователей.
При запуске через консоль команда потребует ввести пароль. Если выполнить команду программно, не через консоль, будет создан пользователь без пароля, он не сможет авторизоваться, пока не будет установлен пароль для него.
Вы можете указать имя пользователя и email с помощью опций --username и --email . Если одна из опций не указана, createsuperuser попросит ввести значение, при запуске команды через консоль.
Опция --database позволяет указать базу данных, в которой будет создан новый пользователь.
django.contrib.gis ¶
ogrinspect¶
Эта команда доступна только при установленном GeoDjango ( django.contrib.gis ).
django.contrib.sessions ¶
clearsessions¶
Может запускаться в кроне или из консоли, чтобы удалить устаревшие данные сессий.
django.contrib.sitemaps ¶
ping_google¶
Эта команда доступна, если установлен Sitemap приложение ( django.contrib.sitemaps ).
django.contrib.staticfiles ¶
collectstatic¶
Команда доступна, если установлено приложение для работы со статикой ( django.contrib.staticfiles ).
findstatic¶
Команда доступна, если установлено приложение для работы со статикой ( django.contrib.staticfiles ).
Опции по умолчанию¶
Каждая команда принимает ряд стандартных опций:
Добавляет указанный путь в пути поиска Python. Если опция не указан, django-admin.py будет использовать переменную окружения PYTHONPATH .
Обратите внимание, эта опция не обязательна при использовании manage.py , т.к. он сам устанавливает необходимые пути поиска Python.
Опция позволяет явно указать модуль настроек, который следует использовать. Путь к модулю должен быть в Python формате, например mysite.settings . Если опция не указана, django-admin.py будет использовать значение переменной окружения DJANGO_SETTINGS_MODULE .
Обратите внимание, эта опция не обязательна при использовании manage.py , т.к. он использует settings.py текущего проекта.
По умолчанию django-admin.py покажет сообщение ошибки для CommandError , и полный трейсбек для остальных ошибок. Опция --traceback указывает django-admin.py выводить полный трейсбек и для CommandError .
Ранее Django не показывал трейсбек для ошибок отличных от CommandError .
Опция --verbosity позволяет указать уровень вывода в консоль сообщений и отладочной информации для django-admin.py .
0 – ничего не выводить.
1 – обычный вывод (по умолчанию).
По умолчанию django-admin.py использует цвета для форматирования вывода. Например, ошибки выводятся красным, а для SQL запросов используется подсветка синтаксиса. Чтобы отключить цветной вывод, используйте опцию --no-color .
Общие опции¶
Следующие опции не доступны для всех команд, но используются большинством из них.
Позволяет указать базу данных, с которой команда должна работать. Если не указана, будет использоваться база данных с меткой default в настройках.
Например, выполнить дамп данных из базы данных с меткой master :
Позволяет исключить приложение из вывода. Например, чтобы исключить приложение auth из вывода dumpdata , выполните:
Чтобы исключить несколько приложений, используйте --exclude несколько раз:
Опция --locale или -l позволяет указать локаль, которая будет использоваться при выполнении команды.
Опция --noinput позволяет отключить все запросы на ввод, такие как просьба подтвердить действия “Are you sure?”. Полезна, если django-admin.py запускает не с консоли, а автоматическим скриптом.
Дополнительные возможности¶
Подсветка синтаксиса¶
Команды django-admin.py / manage.py использует цветной вывод, если терминал поддерживает ANSI-цветной вывод. Если вывод передается в другую команду через “pipe”( | ), цветной выводе не будет использоваться.
Встроенная в Windows консоль не поддерживает цветной вывод. Но вы можете установить ANSICON, Django определить наличие этой библиотеки и будет использовать цветной вывод.
Вы можете настроить цвета для подсветки синтаксиса. Django предоставляет цветовых темы:
dark , удобна для терминалов, которые выводят белый текст на черном фоне. Используется по умолчанию.
light , для терминалов, которые выводят черный текст на белом фоне.
nocolor , отключает подсветку синтаксиса.
Вы можете указать цветную тему, используя переменную окружения DJANGO_COLORS . Например, чтобы использовать light тему в Unix или OS/X BASH, выполните:
Вы можете указать какие цвета использовать. Django предоставляет несколько типов сообщений, для которых можно указать цвет:
error — Важная ошибка.
notice — Незначительная ошибка.
sql_field — Название поля модели в SQL.
sql_coltype — Тип поля модели в SQL.
sql_keyword — Ключевые слова SQL.
sql_table — Название модели в SQL.
http_info — 1XX HTTP Informational ответ сервера.
http_success — 2XX HTTP Success ответ сервера.
http_not_modified — 304 HTTP Not Modified ответ сервера.
http_redirect — 3XX HTTP Redirect ответ сервера, исключая 304.
http_not_found — 404 HTTP Not Found ответ сервера.
http_bad_request — 4XX HTTP Bad Request ответ сервера, исключая 404.
http_server_error — 5XX HTTP Server Error ответ сервера.
Для каждого сообщения можно указать цвет текста и фона. Доступные цвета:
- black
- red
- green
- yellow
- blue
- magenta
- cyan
- white
Можно указать дополнительно следующие параметры:
- bold
- underscore
- blink
- reverse
- conceal
Цвета можно указать в следующем формате:
- role=fg
- role=fg/bg
- role=fg,option,option
- role=fg/bg,option,option
где role – это тип сообщения, fg – цвет текста, bg – цвет фона, а каждая option – один из дополнительных параметров. Настройки для нескольких типов сообщений можно указать через точку с запятой. Например:
укажет показывать ошибки мигающим желтым на синем фоне, а уведомления будут пурпурными. Все остальные сообщения будут бесцветные.
Цвета можно унаследовать от существующей цветовой темы, указав ее название в переменной. Например:
укажет использовать цветы из light темы, кроме сообщений об ошибках и уведомлениях, для которых мы явно указали настройки.
Добавлена поддержка цветного вывода django-admin.py / manage.py на Windows с использованием ANSICON.
Автодополнение в Bash¶
Если вы используете Bash, вы можете установить скрипт автодополнения для Django, который находится в extras/django_bash_completion в пакете Django. Он позволяет автодополнение команд через [TAB] для django-admin.py и manage.py . Теперь вы можете, например.
Нажать [TAB], чтобы увидеть все доступные команды.
Ввести sql , затем [TAB], чтобы увидеть все доступные команды, название которых начинается на sql .
Выполнение команд в коде¶
Чтобы выполнить команду в коде, используйте call_command .
Список аргументов для команды.
Список опций для команды.
Обратите внимание, опции, которые не принимают аргументы, указываются как именованные аргументы функции с True или False :
Опции, которые принимают несколько значений, передаются через список:
Перенаправление вывода¶
Обратите внимание, вы можете перенаправить вывод команды т.к. все команды поддерживают опции stdout и stderr . Например: