Все мы любим pathlib за его краткость, логичность и ООП-подход.
История его появления в стандартных библиотеках это пример как надо интегрировать новые принципы в архитектуру языка программирования или любого приложения.
Расскажу кратко, по этапам:

🔸 Сначала у нас был os.path. Это функциональный подход который выглядит громоздко и многословно.

#пример переименования
import os

my_path = '/path/to/file.ext'
dir_name = os.path.dirname(my_path)
new_name = 'file2' + os.path.splitext(my_path)[1]
new_path = os.path.join(dir_name, new_name)
os.rename(my_path, new_path)

🔸 В версии 3.4 появилась библиотека pathlib которая поменяла ход игры. Теперь работаем с путями как с объектами. Кода стало меньше, счастья больше.

# пример переименования с pathlib
from pathlib import Path

my_path = Path('/path/to/file.ext')
new_path = my_path.with_name('file2').with_suffix(my_path.suffix)
my_path.rename(new_path)

🔸 С приходом этой сущности появились и проблемы, старые методы для работы с путями просто не понимают этот тип. Они работают только со строками.

my_path = Path('/path/to/file.ext')
open(my_path)
TypeError: invalid file: PosixPath('...')

То же самое с subprocess и остальными.

🔸Возникла задача адаптации всех стандартных методов для работы с данной библиотекой. Чтобы каждый из них смог понять объект Path и правильно его обработать. И самое интересное, как это было реализовано.

🔸 Если объект Path конвертнуть в строку str(Path) то мы получим правильный путь. Получается, что надо просто добавить форсированную конвертацию аргументов в str везде где это нужно? Нет!, так мы только всё усложим.

Просить юзеров конвертить в str когда нужно? Тоже нет, не pythonic-way.

В результате в Python 3.6 появляется новый абстрактный класс os.PathLike и понятие path-like object, который понимают все стандартные методы работы с файлами. Теперь, при написании библиотеки для работы с путями, ваша задача следовать правилам этого типа чтобы аккуратно вписаться в экосистему Python-путей.

А правила там простые, magic-метод ˍˍfspathˍˍ (file system path), который возвращает валидный путь.
Все методы для обработки файлов используют os.fspath() для объекта пути перед его использованием.

class MyPath(os.PathLike):
    def __init__(self, val):
        self.val = val

    def __fspath__(self):
        return self.val

path = MyPath('/path/to/file/ext')
f = open(path, 'w')  # PROFIT!!!

Это сработает и без наследования от os.PathLike, Достаточно и только метода ˍˍfspathˍˍ. Но лучше всё же наследоваться, чтобы добавить дополнительные проверки субклассов.

А если наследоваться не получается то можно воспользоваться методом register

os.PathLike.register(MyPath)

Кстати, именно так и поступили в pathlib

🔸 Вывод

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

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

Это принцип за который я сам всегда всеми руками ЗА.
Низкоуровневые решения не должны заниматься частными случаями. Если мы попробуем подстроиться под каждый необычный случай то получим жуткую кашу из if-else, try-except или еще чего похуже.

Когда вас просят поправить ваш api, потому что вот тут в таком-то случае у юзера всё ломается, остановитесь на секунду и подумайте, а точно ли вам нужно делать именно то что просят?

Если ваше решение начинается с if, это неверное решение!

#libs #tricks #pathlib