PRE-PEP: new Path class

Bernhard Herzog bh at intevation.de
Tue Jan 6 15:29:32 EST 2004


"John Roth" <newsgroups at jhrothjr.com> writes:

> 5) Should == operator be the same as os.path.samefile()?
>
> Why not...

ISTM, that it would essentially make path objects non-hashable.
posixpath.samefile compares the os.stat values for both filenames.
These values can change over time vor various reasons so object equality
changes too.  That it changes is desired, obviously, but what do you use
as hash value?  p1 == p2 has to imply that hash(p1) == hash(p2) but the
only way to achieve that is to give all path objects the same hash
value.  That would make dicts with path objects as keys very
inefficient, though.

As for the path objects in general: Cute idea, but IMO strings for
filenames work fine and there's nothing unpythonic about it.  The
virtual filesytem bit seems like a good reason not to introduce the path
type just yet:

> 2) virtual file system extensibility.
>
> No opinion at this time. I'd like to see a couple
> of attempts at an implementation first before
> settling on a single design.

At this point it doesn't seem clear what virtual filesystems would mean
for Python, so it's unclear, too, what it would mean for a Path class.
Introduce a Path class once there is a need for having several distinct
classes, not earlier.

   Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
Thuban                                  http://thuban.intevation.org/



More information about the Python-list mailing list