It's controversial that Path subclasses str. Some people think it's
flat-out wrong. Even Bjorn argues that it's a practicality-vs-purity
tradeoff. But a strong argument can be made that Path *should* be a
string subclass, practicality be damned. Proof follows.
I. Here's an example of the sort of thing you might say if you did
*not* think of paths as strings:
On 1/25/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> I think it's logical to expect that
> Path('home') / 'and/or'
> points to a file named "and/or" in directory "home", not to a file
> named "or" in directory "home/and".
This makes no sense whatsoever. Ergo, by reductio ad absurdum, paths
are strings.
II. And here is the sort of thing you'd say if you thought of paths
*solely* as strings:
> (2) Note that '/' is also the path separator used by URIs, which RFC
> 2396 gives different semantics from Unix. Most of my Python usage to
> date has been heavily web-oriented, and I'd have little use for /
> unless it follows RFC 2396.
The quandary is resolved by pointing out that URIs are not paths (in
the sense of os.path and generally this whole horrible thread). Thus
not all strings are paths.
Hence the paths are a proper subset of the strings. By the existence
of os.path, they have their own commonly-used operations. By
definition, then, Path is a subclass of string, QED.
Do I really buy all this? I dunno. To say "paths aren't strings" is
all very well, and in a very abstract sense I almost agree--but you
have to admit it sort of flies in the face of, you know, reality.
Filesystem paths are in fact strings on all operating systems I'm
aware of. And it's no accident or performance optimization. It's
good design.
-j
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
