Пути Unix: официально работать в Python для любой платформы?

Question

Могут ли все пути в программе Python использовать ".." (для родительского каталога) и / (для разделения компонентов пути), и при этом работать независимо от платформы ?

С одной стороны, я никогда не видел такого утверждения в документации (возможно, я его пропустил), а модули os и os.path предоставляют средства для обработки путей независимо от платформы (os.pardir, os .path.join,…), что позволяет мне думать, что они здесь по причине.

С другой стороны, вы можете прочитать в StackOverflow , что "../path/to/file" работает на всех платформах ...

Итак, следует ли всегда использовать os.pardir, os.path.join и друзей в целях переносимости или всегда безопасны пути Unix (вплоть до возможных проблем с кодировкой символов)? или, может быть, «почти всегда» безопасно (т.е. работает под Windows, OS X и Linux)?

Answer 1

У меня никогда не было проблем с использованием .., хотя было бы неплохо преобразовать его в абсолютный путь, используя 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 все поддерживают эту нотацию).

Answer 2

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

Тем не менее, 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 - разделитель альтернативных путей (нет или '/') os.pathsep - это разделитель компонентов, используемый в $ PATH и т. д. os.linesep - разделитель строк в текстовых файлах ('' или '' или '') os.defpath - это путь поиска по умолчанию для исполняемых файлов

Программы, которые импортируют и используют 'os', имеют больше шансов быть портативный между различными платформами. Конечно, они должны только тогда использовать функции, которые определены всеми платформами (например, unlink и opendir) и оставьте все манипуляции с именами путей к os.path (например, split и присоединяйтесь).

Answer 3

Он работает в Windows, поэтому, если вы определите «какую бы платформу» не называли Unix и Windows, все в порядке.

С другой стороны, Python также работает на VMS, RISC OS и других странных платформах, которые используют совершенно разные соглашения об именах файлов. Тем не менее, вполне вероятно, что пытаться заставить ваше приложение работать на VMS, вслепую, все равно глупо - «преждевременная переносимость - корень некоторого относительно небольшого зла»

Мне все равно нравится использовать функции os.path, потому что они хороши для выражения намерения - вместо простой конкатенации строк, которая может быть сделана для любой из миллионов целей, она очень явно читается как манипулирование путями.

Answer 4

Windows поддерживает / в качестве разделителя пути. Единственные несовместимости между именами файлов Unix и именами Windows:

• разрешенные символы в именах файлов
• специальные имена и
• чувствительность к регистру

Windows более ограничена в первых двух учетных записях (то есть имеет больше запрещенных символов и больше специальных имен), тогда как Unix обычно чувствителен к регистру. Здесь есть ответы , в которых перечисляются именно эти символы и имена. Я посмотрю, смогу ли я их найти.

Теперь, если в вашей среде разработки есть функция для создания или манипулирования путями, вы должны использовать ее, она существует по какой-то причине, понимаете. Особенно с учетом того, что платформ намного больше, чем Windows и Unix.

Отвечая на ваш первый вопрос, да ../dir/file сработает, если только они не затронут некоторые из вышеупомянутых несовместимостей.

Answer 5

В Python использование / всегда будет работать. Вам нужно знать соглашение об ОС, если вы хотите выполнить команду в подоболочке

myprog = "/path/to/my/program"
os.system([myprog, "-n"])                           # 1
os.system([myprog, "C:/input/file/to/myprog"])      # 2

Команда # 1, вероятно, будет работать как положено.
Команда # 2 может не работать, если myprog - это команда Windows и ожидает синтаксического анализа своих аргументов командной строки для получения имени файла Windows.

Answer 6

OS / X и Linux совместимы с Unix, поэтому по определению они используют формат, который вы указали в начале вопроса. Windows допускает использование «/» в дополнение к «\», чтобы программы могли быть взаимозаменяемыми с Xenix, вариантом Unix, который Microsoft давно опробовал, и эта совместимость была перенесена в настоящее время. Таким образом, это тоже работает.

Я не знаю, сколько других платформ было портировано на Python, и я не могу говорить за них.

Answer 7

Как уже говорили другие, косая черта будет работать во всех случаях, но вам лучше создать список сегментов пути и os.path.join () - их.