Unix-пути, которые работают для любой платформы в Python?
Могут ли все пути в программе Python использовать ".." (для родительского каталога) и/(для разделения компонентов пути) и все равно работать независимо от платформы?
С одной стороны, я никогда не видел такой претензии в документации (возможно, я ее пропустил), а модули os и os.path предоставляют средства для обработки путей в агностическом режиме платформы (os.pardir, os.path.join,...), что позволяет мне думать, что они здесь по какой-то причине.
С другой стороны, вы можете qaru.site/info/67791/..., что "../path/to/file" работает на всех платформах...
Итак, должны ли os.pardir, os.path.join и друзья всегда использоваться, для целей переносимости, или имена путей Unix всегда безопасны (вплоть до возможных проблем с кодировкой символов)? или, может быть, "почти всегда" безопасно (т.е. работает под Windows, OS X и Linux)?
Ответы
Ответ 1
"Почти всегда безопасно" правильно. Все платформы, о которых вы заботитесь, вероятно, хорошо работают сегодня, и я не думаю, что они скоро изменят свои соглашения.
Однако Python очень портативен и работает на гораздо большем, чем обычные платформы. Причина для модуля os
заключается в том, чтобы помочь сгладить его, у платформы есть разные требования.
Есть ли веская причина, почему вы не используете функции os
?
os.pardir
является самодокументированным, тогда как ".."
нет, а os.pardir может быть легче grep для
Вот некоторые документы из python 1.6, когда Mac по-прежнему отличался для всех
Подпрограммы ОС для Mac, DOS, NT или Posix в зависимости от того, какая система мы на.
Этот экспорт: - все функции из posix, nt, dos, os2, mac или ce, например. unlink, stat и т.д. - os.path - это один из модулей posixpath, ntpath, macpath или dospath - os.name - это 'posix', 'nt', 'dos', 'os2', 'mac' или 'ce' - os.curdir - это строка, представляющая текущий каталог ('.' или ':') - os.pardir - это строка, представляющая родительский каталог ( ".." или "::" ) - os.sep является (или наиболее распространенным) разделителем пути ('/' или ':' или '\') - os.altsep - это альтернативный разделитель пути (None или '/') - os.pathsep - это разделитель компонентов, используемый в $PATH и т.д. - os.linesep - разделитель строк в текстовых файлах ('' или '' или '') - os.defpath - это путь поиска по умолчанию для исполняемых файлов
Программы, которые импортируют и используют "os", имеют больше шансов быть переносимый между различными платформами. Конечно, тогда они должны использовать функции, определенные всеми платформами (например, unlink и opendir) и оставить все манипуляции с именем пути в os.path(например, split и присоединитесь).
Ответ 2
У меня никогда не было проблем с использованием ..
, хотя было бы неплохо преобразовать его в абсолютный путь, используя os.path.abspath. Во-вторых, я бы рекомендовал всегда использовать os.path.join везде. Есть много угловых случаев (кроме проблем с переносимостью) при соединении путей, и им не нужно беспокоиться о них. Например:
>>> '/foo/bar/' + 'qux'
'/foo/bar/qux'
>>> '/foo/bar' + 'qux'
'/foo/barqux'
>>> from os.path import join
>>> join('/foo/bar/', 'qux')
'/foo/bar/qux'
>>> join('/foo/bar', 'qux')
'/foo/bar/qux'
У вас могут возникнуть проблемы с использованием ..
, если вы находитесь на некоторых неясных платформах, но я не могу назвать их (Windows, * nix и OS X поддерживают эту нотацию).
Ответ 3
Внутри python всегда будет работать /
. Вам нужно будет знать соглашение OS, если вы хотите выполнить команду в подоболочке
myprog = "/path/to/my/program"
os.system([myprog, "-n"]) # 1
os.system([myprog, "C:/input/file/to/myprog"]) # 2
Команда # 1, вероятно, будет работать так, как ожидалось.
Команда №2 может не работать, если myprog
является командой Windows и ожидает, что она будет разбирать ее аргументы командной строки, чтобы получить имя файла Windows.
Ответ 4
Windows поддерживает /
как разделитель путей. Единственная несовместимость между именами файлов Unix и именами файлов Windows:
- допустимые символы в именах файлов
- специальные имена и
- чувствительность к регистру
Windows более ограничительна в первых двух учетных записях (это значит, что у нее больше запрещенных символов и более специальных имен), а Unix - обычно чувствительны к регистру. Есть несколько ответов, в которых перечислены именно эти символы и имена. Я посмотрю, смогу ли я их найти.
Теперь, если в вашей среде разработки есть функция для создания или манипуляции с путями, вы должны использовать ее, она там по какой-то причине. Особенно учитывая, что существует намного больше платформ, чем Windows и Unix.
Отвечая на ваш первый вопрос, да ../dir/file
будет работать, если они не ударят по некоторым из вышеупомянутых несовместимостей.
Ответ 5
Он работает в Windows, поэтому, если вы определите, что "любая платформа" будет Unix и Windows, вы в порядке.
С другой стороны, Python также работает на VMS, RISC OS и других нечетных платформах, которые используют совершенно разные соглашения об именах файлов. Тем не менее, вероятно, что попытка заставить ваше приложение работать на VMS, слепое, в любом случае является глупым - "преждевременная переносимость - корень некоторого относительно незначительного зла"
Мне нравится использовать функции os.path в любом случае, потому что они хороши для выражения намерения - вместо просто конкатенации строк, которая может быть выполнена для любого из миллионов целей, она читается очень явно как манипуляция с путями.
Ответ 6
OS/X и Linux совместимы с Unix, поэтому по определению они используют формат, который вы дали в начале вопроса. Windows позволяет "/" в дополнение к "\", чтобы программы могли быть взаимозаменяемыми с Xenix, вариантом Unix, который Microsoft давно пыталась использовать, и эта совместимость переносилась в настоящее. Таким образом, он работает тоже.
Я не знаю, сколько других платформ Python было перенесено, и я не могу говорить за них.
Ответ 7
Как говорили другие, во всех случаях будет работать косая черта, но вам лучше создать список сегментов пути и os.path.join().