Как проверить, существует ли файл при помощи python

Второй пример: использование предварительно созданного виртуального окружения

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

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

В этом примере мы создадим виртуальное окружения PySide2, куда установим данную библиотеку. Затем создадим программу, использующую библиотеку PySide2 из предварительно созданного виртуального окружения. Программа будет показывать метку, отображающую версию установленной библиотеки PySide2.

Начнем с экран приветствия PyCharm. Для этого нужно выйти из текущего проекта. На экране приветствия в нижнем правом углу через Configure → Settings переходим в настройки. Затем переходим в раздел Project Interpreter. В верхнем правом углу есть кнопка с шестерёнкой, нажимаем на неё и выбираем Add…, создавая новое окружение. И указываем расположение для нового окружения. Имя конечной директории будет также именем самого окружения, в данном примере — . В Windows можно поменять в пути папку на , чтобы команда находила создаваемые в PyCharm окружения. Нажимаем на ОК.

Далее в созданном окружении устанавливаем пакет с библиотекой PySide2, также как мы устанавливали matplotlib. И выходим из настроек.

Теперь мы можем создавать новый проект использующий библиотеку PySide2. В окне приветствия выбираем Create New Project.

В мастере создания проекта, указываем имя расположения проекта в поле Location. Разворачиваем параметры окружения, щелкая по Project Interpreter, где выбираем Existing interpreter и указываем нужное нам окружение .

Для проверки работы библиотеки создаем файл со следующий кодом:

Далее создаем конфигурацию запуска программы, также как создавали для первого примера. После чего можно выполнить программу.

Переменные окружения для Python проектов

При разработки web-приложения или бота мы часто имеем дело с какой-либо секретной информацией, различными токенами и паролями (API-ключами, секретами веб-форм). «Хардкодить» эту информацию, а тем более сохранять в публично доступной системе контроля версий это очень плохая идея.

Конфигурационные файлы

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

Переменные окружения

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

С помощью переменных окружения можно получать различные параметры приложение и секретные ключи:

Библиотека python-dotenv

Теперь можно создать файл .env со всеми переменными среды, которые необходимы вашему приложению

Важно, добавьте -файл в , не храните его в системе контроля версий

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

Утилита direnv

Установка direnv

Далее необходимо в нести изменения для настройки нашей оболочки, для bash необходимо в конец файла добавить следующее и перезапустить консоль:

Создание виртуального окружения

Если в файл добавить строчку

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

Таким же способом можно подключать уже созданное виртуальное окружение.

Создаем строку приглашения bash (PS1)

В отличие от ручной активации виртуального окружения, в нашем случае строка приглашения bash (PS1) не будет изменена (обычно она выглядит как ). Чтобы вернуть показ активации виртуального окружения в консоли нужно в файл добавить следующий код:

Пример файла настройки файла

Вот так может выглядеть файл настроенный для разработки flask-приложения:

Это позволяет автоматически активировать виртуальное окружение и загрузить переменные окружения при входе в папку с проектом.

Comparisons

Paths of the same flavour are comparable and orderable, whether pure or not:

>>> PurePosixPath('a') == PurePosixPath('b')
False
>>> PurePosixPath('a') < PurePosixPath('b')
True
>>> PurePosixPath('a') == PosixPath('a')
True

Comparing and ordering Windows path objects is case-insensitive:

>>> PureWindowsPath('a') == PureWindowsPath('A')
True

Paths of different flavours always compare unequal, and cannot be ordered:

>>> PurePosixPath('a') == PureWindowsPath('a')
False
>>> PurePosixPath('a') < PureWindowsPath('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unorderable types: PurePosixPath() < PureWindowsPath()

Unit Testing Improvements

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

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

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

Здесь я создаю подкласс класса приложения и переопределяю конфигурацию SQLAlchemy для использования базы данных SQLite в памяти. Я также добавил атрибут со значением True, который в настоящее время мне не нужен, но может быть полезен, если приложение должно определить, выполняется ли оно в модульных тестах или нет.

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

Новое приложение будет храниться в , но создания приложения недостаточно, чтобы все работало. Рассмотрим инструкцию , которая создает таблицы базы данных. Экземпляр должен знать, что такое экземпляр приложения, потому что ему нужно получить URI базы данных из , но когда вы работаете с фабрикой приложений, вы на самом деле не ограничены одним приложением, может быть создано гораздо больше одного. Итак, как же узнает, что должен использовать экземпляр , который я только что создал?

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

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

Вы также должны знать, что контекст приложения является одним из двух контекстов, которые использует Flask. Существует также request context, что более конкретно, поскольку это относится к запросу. Когда контекст запроса активируется непосредственно перед обработкой запроса, становятся доступными переменные и Flask, а также Flask-Login.

sys.argv

Значение sys.argv – это список аргументов командной строки, которые причастны к скрипту Python. Первый аргумент, argv, имеет аналогичное скрипту Python наименование. В зависимости от платформы, на которой вы работаете, первый аргумент может содержать полный путь к скрипту или к названию файла. Для дополнительных деталей обратитесь к документации. А тем временем, попробуем поработать с парочкой примеров, чтобы познакомиться с этим инструментом:

Python

import sys
print(sys.argv)
# Ответ:

Если вы запустите это в интерпретаторе, вы получите список с пустой строкой. Давайте создадим файл под названием sysargv.py, со следующим содержимым:

Python

import sys

print(sys.argv)

Теперь запустите код в IDLE. Вы увидите список с одним элементом, который содержит путь к вашему скрипту. Попробуем передать скрипту несколько аргументов. Откройте окно терминала \ консоли и при помощи команды cd измените каталоги на тот, в котором находится скрипт. После этого, запустите что-то наподобие этого:

sys.argv

Обратите внимание на то, что будет выведено на экран:

Python

Первый аргумент – это название файла нашего скрипта. Следующие два аргумента в списке – это те, что мы передали нашему скрипту в командной строке.

Sequence-like access

The parts property returns a tuple providing read-only sequence access
to a path’s components:

>>> p = PurePosixPath('/etc/init.d')
>>> p.parts
('/', 'etc', 'init.d')

Windows paths handle the drive and the root as a single path component:

>>> p = PureWindowsPath('c:/setup.py')
>>> p.parts
('c:\\', 'setup.py')

(separating them would be wrong, since C: is not the parent of C:\\).

The parent property returns the logical parent of the path:

>>> p = PureWindowsPath('c:/python33/bin/python.exe')
>>> p.parent
PureWindowsPath('c:/python33/bin')

The parents property returns an immutable sequence of the path’s
logical ancestors: