5

В версии Python3.6 запланирован (тем не менее об этом нигде прямо не говорится, кроме строчки "Python-Version") релиз нового волшебного метода __fspath__ (https://www.python.org/dev/peps/pep-0519). В описании сказано вроде бы ясно:

The goal is to facilitate the migration of users towards rich path objects while providing an easy way to work with code expecting str or bytes.

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

Тем не менее, не совсем понятно несколько моментов:

Для кого это обновление? О каких пользователях идет речь? Каков будет типичный пример использования, будь то в библиотеках или в прикладных программах?

Обычно я, как обыкновенный пользователь, пишу что-то вроде:

project_path = os.path.realpath(os.path.dirname(__file__))
config_path = os.path.join(project_path, 'configs', 'sub_configs', 'my_super_config.ini')
conf = open(config_path, 'r', encoding="utf-8")

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

m9_psy
  • 6,449

2 Answers2

2

Потому что вызов str(path) чреват ошибками. str(obj) работает для любого объекта в Питоне, но не все объекты представляют пути. Пример из PEP 519: open(str(None), 'w') может молча создать файл, вместо выбрасывания ошибки. os.fspath(path) возвращает представление path, подходящее для файловой системы и позволяет избежать silent errors:

>>> import os
>>> os.fspath(None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: expected str, bytes or os.PathLike object, not <class 'NoneType' at ...>

Примеры кандидатов для __fspath__ протокола: pathlib.Path, os.DirEntry (генерируются os.scandir()).

Ваш пример, можно так переписать:

from pathlib import Path
import appdirs  # $ pip install appdirs

path = Path(appdirs.user_data_dir(appname, appauthor))
config_path = path / 'configs' / 'sub_configs' / 'my_super_config.ini'
conf = config_path.open(encoding="utf-8")

Если вы действительно данные из файла, расположенного относительно установленного модуля, хотите, то используйте pkgutil.get_data() или setuptools' pkg_resources.resource_string().

В данном случае разницы особой нет между os.path функциями и pathlib интерфейсом. Но в целом есть преимущества в использовании специальных объектов для путей вместо общих строк—из PEP 519:

At issue is the fact that while all file system paths can be represented as strings or bytes, not all strings or bytes represent a file system path. This can lead to issues where any e.g. string duck-types to a file system path whether it actually represents a path or not.

Как продемонстрировано ошибкой наверху ответа иногда строки, которые не являются путями (str(None)), могут случайно как пути быть интерпретированы, а специальные объекты такие как pathlib.Path не имеют этого недостатка.

Плюс, специальный объект может предоставлять более богатый специальный интерфейс, например, path.read_text(). Существуют и существовали модули, использующие объекты для представления путей, например: path.py.

На практике, если есть возможность использовать Питон 3 или поставить pathlib на Питон 2, то код, который с файловой системой работает, приятней с pathlib.Path/os.DirEntry писать. Вот примеры кода, где pathlib делает код более читаемым. Вот примеры, где одна и та же функциональность реализована с и без os.scandir():

Дух сообщества
  • 1
jfs
  • 52,361
  • По ответу получается, что сие решает проблему str(foo)e Но зачем вообще вызывать str? open(None) вполне себе ругается и проблем не вызывает. – andreymal Jun 14 '16 at 22:48
  • @andreymal open() ожидает str/bytes и поэтому path-like объекты необходимо в str/bytes конвертировать. Чтобы обычные filesystem функции (например такие как в importlib), которые уже работают со строками могли безопасно поддерживать path-like объекты (вместо небезопасного str(path), os.fspath() вызывается где-нибудь глубоко в кишках функций, вызываемых importlib) что позволит их более широко использовать. Использование специальных объектов вместо строк для путей может сделать код более читаемым, переносимым и иногда более эффективным и менее подверженному к ошибкам. – jfs Jun 14 '16 at 23:03
  • Если я не буду использовать path-like объекты, то и str не надо вызывать будет, а остальное пустые слова какие-то) – andreymal Jun 15 '16 at 06:31
  • @andreymal: вы имеете право на своё мнение, но вы не имеете право на свои факты. Например, попробуйте написать более читаемый, эффективный и переносимый код, не используя os.scandir() или похожих path-like объектов, для примера из ссылки в ответе. Если сможете, тогда ваш комментарий не является просто безграмотным необоснованным и неспровоцированным оскорблением. – jfs Jun 15 '16 at 11:27
  • допустим, я не написал код, тогда получается, что path-like объекты следует использовать, только потому что итератор os.scandir() возвращает именно их. А зачем он возвращает именно их, а не (байтовые) строки? Бегло пробежавшись по PEP 471, ответа я не обнаружил (кэширование — не наш случай). – andreymal Jun 15 '16 at 11:56
  • @andreymal: неверно. Я разрешаю вам придумать своё filesystem API, которое использует str/bytes, если не можете написать код, используя существующее str/bytes API (что уже является фактом, в пользу path-like объектов), но приведите "более читаемый, эффективный и переносимый код" — код, а не "пустые слова". – jfs Jun 15 '16 at 12:13
  • ну это всё ещё не ответ на вопрос, зачем scandir возвращает path-like объекты. Мой код, независимо от его наличия или отсутствия, на него не ответит. (Но я его попробую написать в ближайшее свободное время.) – andreymal Jun 15 '16 at 12:28
  • Пусть будет чат, ибо это уже мои собственные тараканы в голове, к вопросу имеющие весьма посредственное отношение.) – andreymal Jun 15 '16 at 12:29
  • @andreymal это имеет прямое отношение к вопросу, потому что если бы было доказательство, что path-like не несут пользы (достаточной, чтобы поддержку в stdlib встраивать), то и os.fspath() не было бы (для str/bytes эта функция ничего не делает). Хотя, конечно, вы можете, если хотите, прямой вопрос про path-like объекты задать, но аргументы те же что и в моём ответе (можно более детально обсудить почему surrogateescape существует, или почему следует Unicode API использовать на Windows, или упомянуть другие path.py реализации, или почему os.DirEntry более переносимо, читаемо и эффективно). – jfs Jun 15 '16 at 12:45
1

Это решает проблемы, которые возникают при использовании продвинутые объекты, представляющие файловые пути с модулем pathlib. Например сейчас невозможно использовать объект типа PurePath чтобы октрыть файл, необходимо конвертировать в string

>>> from pathlib import PurePath
>>> path = 'workspace'
>>> p = PurePath(path) / 'where.txt'
>>> with open(p) as f:
...     print(f.readline())
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: invalid file: PurePosixPath('workspace/where.txt')

>>> with open(str(p)) as f:
...     print(f.readline())
... 
spam foo, bar, baz

__fspath__ решает это:

To help elevate the representation of file system paths from their representation as strings and bytes to a richer object representation, the pathlib module [4] was provisionally introduced in Python 3.4 through PEP 428 . While considered by some as an improvement over strings and bytes for file system paths, it has suffered from a lack of adoption. Typically the key issue listed for the low adoption rate has been the lack of support in the standard library. This lack of support required users of pathlib to manually convert path objects to strings by calling str(path) which many found error-prone.

One issue in converting path objects to strings comes from the fact that the only generic way to get a string representation of the path was to pass the object to str() . This can pose a problem when done blindly as nearly all Python objects have some string representation whether they are a path or not, e.g. str(None) will give a result that builtins.open() [5] will happily use to create a new file.

Дух сообщества
  • 1
Sede
  • 581