iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

NTPath becomes WindowsPath

This commit is contained in:
Antoine Pitrou 2013-11-16 22:31:45 +01:00
parent 0866846d15
commit 193c166121
1 changed files with 50 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

100
pep-0428.txt
View File

@ -98,11 +98,11 @@ The `pathlib`_ module implements a simple hierarchy of classes::
| | |
| | |
v | v
+---------------+ | +------------+
| | | | |
| PurePosixPath | | | PureNTPath |
| | | | |
+---------------+ | +------------+
+---------------+ | +-----------------+
| | | | |
| PurePosixPath | | | PureWindowsPath |
| | | | |
+---------------+ | +-----------------+
| v |
| +------+ |
| | | |
@ -112,11 +112,11 @@ The `pathlib`_ module implements a simple hierarchy of classes::
| | | |
| | | |
v v v v
+-----------+ +--------+
| | | |
| PosixPath | | NTPath |
| | | |
+-----------+ +--------+
+-----------+ +-------------+
| | | |
| PosixPath | | WindowsPath |
| | | |
+-----------+ +-------------+
This hierarchy divides path classes along two dimensions:
@ -132,15 +132,15 @@ This hierarchy divides path classes along two dimensions:
other systems (``os.name``'s terminology is re-used here).
Any pure class can be instantiated on any system: for example, you can
manipulate ``PurePosixPath`` objects under Windows, ``PureNTPath`` objects
under Unix, and so on. However, concrete classes can only be instantiated
on a matching system: indeed, it would be error-prone to start doing I/O
with ``NTPath`` objects under Unix, or vice-versa.
manipulate ``PurePosixPath`` objects under Windows, ``PureWindowsPath``
objects under Unix, and so on. However, concrete classes can only be
instantiated on a matching system: indeed, it would be error-prone to start
doing I/O with ``WindowsPath`` objects under Unix, or vice-versa.
Furthermore, there are two base classes which also act as system-dependent
factories: ``PurePath`` will instantiate either a ``PurePosixPath`` or a
``PureNTPath`` depending on the operating system. Similarly, ``Path``
will instantiate either a ``PosixPath`` or a ``NTPath``.
``PureWindowsPath`` depending on the operating system. Similarly, ``Path``
will instantiate either a ``PosixPath`` or a ``WindowsPath``.
It is expected that, in most uses, using the ``Path`` class is adequate,
which is why it has the shortest name of all.
@ -189,17 +189,17 @@ Paths of the same flavour are comparable and orderable, whether pure or not::
Comparing and ordering Windows path objects is case-insensitive::
>>> PureNTPath('a') == PureNTPath('A')
>>> PureWindowsPath('a') == PureWindowsPath('A')
True
Paths of different flavours always compare unequal, and cannot be ordered::
>>> PurePosixPath('a') == PureNTPath('a')
>>> PurePosixPath('a') == PureWindowsPath('a')
False
>>> PurePosixPath('a') < PureNTPath('a')
>>> PurePosixPath('a') < PureWindowsPath('a')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unorderable types: PurePosixPath() < PureNTPath()
TypeError: unorderable types: PurePosixPath() < PureWindowsPath()
Useful notations
@ -280,14 +280,14 @@ the information from the previously joined components::
However, with Windows paths, the drive is retained as necessary::
>>> PureNTPath('c:/foo', '/Windows')
PureNTPath('c:\\Windows')
>>> PureNTPath('c:/foo', 'd:')
PureNTPath('d:')
>>> PureWindowsPath('c:/foo', '/Windows')
PureWindowsPath('c:\\Windows')
>>> PureWindowsPath('c:/foo', 'd:')
PureWindowsPath('d:')
Also, path separators are normalized to the platform default::
>>> PureNTPath('a/b') == PureNTPath('a\\b')
>>> PureWindowsPath('a/b') == PureWindowsPath('a\\b')
True
Extraneous path separators and ``"."`` components are eliminated, but not
@ -302,8 +302,8 @@ Multiple leading slashes are treated differently depending on the path
flavour. They are always retained on Windows paths (because of the UNC
notation)::
>>> PureNTPath('//some/path')
PureNTPath('\\\\some\\path\\')
>>> PureWindowsPath('//some/path')
PureWindowsPath('\\\\some\\path\\')
On POSIX, they are collapsed except if there are exactly two leading slashes,
which is a special case in the POSIX specification on `pathname resolution`_
@ -332,7 +332,7 @@ To represent a path (e.g. to pass it to third-party libraries), just call
>>> p = PurePath('/home/antoine/pathlib/setup.py')
>>> str(p)
'/home/antoine/pathlib/setup.py'
>>> p = PureNTPath('c:/windows')
>>> p = PureWindowsPath('c:/windows')
>>> str(p)
'c:\\windows'
@ -353,7 +353,7 @@ To represent the path as a ``file`` URI, call the ``as_uri()`` method::
>>> p = PurePosixPath('/etc/passwd')
>>> p.as_uri()
'file:///etc/passwd'
>>> p = PureNTPath('c:/Windows')
>>> p = PureWindowsPath('c:/Windows')
>>> p.as_uri()
'file:///c:/Windows'
@ -363,7 +363,7 @@ Properties
Seven simple properties are provided on every path (each can be empty)::
>>> p = PureNTPath('c:/Downloads/pathlib.tar.gz')
>>> p = PureWindowsPath('c:/Downloads/pathlib.tar.gz')
>>> p.drive
'c:'
>>> p.root
@ -414,31 +414,31 @@ Changing the path's final component
The ``with_name()`` method returns a new path, with the name changed::
>>> p = PureNTPath('c:/Downloads/pathlib.tar.gz')
>>> p = PureWindowsPath('c:/Downloads/pathlib.tar.gz')
>>> p.with_name('setup.py')
PureNTPath('c:\\Downloads\\setup.py')
PureWindowsPath('c:\\Downloads\\setup.py')
It fails with a ``ValueError`` if the path doesn't have an actual name::
>>> p = PureNTPath('c:/')
>>> p = PureWindowsPath('c:/')
>>> p.with_name('setup.py')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pathlib.py", line 875, in with_name
raise ValueError("%r has an empty name" % (self,))
ValueError: PureNTPath('c:\\') has an empty name
ValueError: PureWindowsPath('c:\\') has an empty name
>>> p.name
''
The ``with_suffix()`` method returns a new path with the suffix changed.
However, if the path has no suffix, the new suffix is added::
>>> p = PureNTPath('c:/Downloads/pathlib.tar.gz')
>>> p = PureWindowsPath('c:/Downloads/pathlib.tar.gz')
>>> p.with_suffix('.bz2')
PureNTPath('c:\\Downloads\\pathlib.tar.bz2')
>>> p = PureNTPath('README')
PureWindowsPath('c:\\Downloads\\pathlib.tar.bz2')
>>> p = PureWindowsPath('README')
>>> p.with_suffix('.bz2')
PureNTPath('README.bz2')
PureWindowsPath('README.bz2')
Making the path relative
^^^^^^^^^^^^^^^^^^^^^^^^
@ -478,9 +478,9 @@ slicing returns a new path object constructed from the selected components::
Windows paths handle the drive and the root as a single path component::
>>> p = PureNTPath('c:/setup.py')
>>> p = PureWindowsPath('c:/setup.py')
>>> p.parts
<PureNTPath.parts: ['c:\\', 'setup.py']>
<PureWindowsPath.parts: ['c:\\', 'setup.py']>
>>> p.root
'\\'
>>> p.parts[0]
@ -491,21 +491,21 @@ Windows paths handle the drive and the root as a single path component::
The ``parent()`` method returns an ancestor of the path::
>>> p.parent()
PureNTPath('c:\\python33\\bin')
PureWindowsPath('c:\\python33\\bin')
>>> p.parent(2)
PureNTPath('c:\\python33')
PureWindowsPath('c:\\python33')
>>> p.parent(3)
PureNTPath('c:\\')
PureWindowsPath('c:\\')
The ``parents()`` method automates repeated invocations of ``parent()``, until
the anchor is reached::
>>> p = PureNTPath('c:/python33/bin/python.exe')
>>> p = PureWindowsPath('c:/python33/bin/python.exe')
>>> for parent in p.parents(): parent
...
PureNTPath('c:\\python33\\bin')
PureNTPath('c:\\python33')
PureNTPath('c:\\')
PureWindowsPath('c:\\python33\\bin')
PureWindowsPath('c:\\python33')
PureWindowsPath('c:\\')
Querying
@ -519,15 +519,15 @@ as ``CON`` or ``NUL``. It always returns False for POSIX paths.
``match()`` matches the path against a glob pattern::
>>> PureNTPath('c:/PATHLIB/setup.py').match('c:*lib/*.PY')
>>> PureWindowsPath('c:/PATHLIB/setup.py').match('c:*lib/*.PY')
True
``normcase()`` returns a case-folded version of the path for NT paths::
>>> PurePosixPath('CAPS').normcase()
PurePosixPath('CAPS')
>>> PureNTPath('CAPS').normcase()
PureNTPath('caps')
>>> PureWindowsPath('CAPS').normcase()
PureWindowsPath('caps')
Concrete paths API