[Python-checkins] peps: NTPath becomes WindowsPath
antoine.pitrou
python-checkins at python.org
Sat Nov 16 22:31:53 CET 2013
http://hg.python.org/peps/rev/c381244b5e63
changeset: 5281:c381244b5e63
user: Antoine Pitrou <solipsis at pitrou.net>
date: Sat Nov 16 22:31:45 2013 +0100
summary:
NTPath becomes WindowsPath
files:
pep-0428.txt | 100 +++++++++++++++++++-------------------
1 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/pep-0428.txt b/pep-0428.txt
--- a/pep-0428.txt
+++ b/pep-0428.txt
@@ -98,11 +98,11 @@
| | |
| | |
v | v
- +---------------+ | +------------+
- | | | | |
- | PurePosixPath | | | PureNTPath |
- | | | | |
- +---------------+ | +------------+
+ +---------------+ | +-----------------+
+ | | | | |
+ | PurePosixPath | | | PureWindowsPath |
+ | | | | |
+ +---------------+ | +-----------------+
| v |
| +------+ |
| | | |
@@ -112,11 +112,11 @@
| | | |
| | | |
v v v v
- +-----------+ +--------+
- | | | |
- | PosixPath | | NTPath |
- | | | |
- +-----------+ +--------+
+ +-----------+ +-------------+
+ | | | |
+ | PosixPath | | WindowsPath |
+ | | | |
+ +-----------+ +-------------+
This hierarchy divides path classes along two dimensions:
@@ -132,15 +132,15 @@
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 @@
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 @@
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 @@
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 @@
>>> 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 @@
>>> 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 @@
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 @@
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 @@
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 @@
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 @@
``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
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list