os.path and Path

[Ethan Furman]

Steven D'Aprano wrote:
> On Wed, 15 Jun 2011 19:00:07 -0700, Ethan Furman wrote:
> 
>> Thread 1: "objects of different types compare unequal" self:    
>> "nonsense!  we have the power to say what happens in __eq__!"
>>
>> Thread 2: "objects that __hash__ the same *must* compare __eq__!" self: 
>>    "um, what? ... wait, only immutable objects hash..."
> 
> Incorrect. 
> What you mean to say is that if objects compare equal, they must hash the 
> same. Not the other way around.

Ack.  I keep saying that backwards.  Thanks for the correction.


>> Thread 2: "you're Path object is immutable..." self:     "argh!"
>>
>> Here's the rub:  I'm on Windows (yes, pity me...) but I prefer the
>> unices, so I'd like to have / seperate my paths.  But I'm on Windows...
> 
> Any sensible Path object should accept path components in a form 
> independent of the path separator, and only care about the separator when 
> converting to and from strings.

Our ideas of 'sensible' apparently differ.

One of my goals with my Path objects was to be a drop-in replacement for 
the strings currently used as paths; consequently, they are a sub-class 
of string, and can still be passed to, for example, os.path.splitext(). 
  Another was to be able to use '/' across all platforms, but still have 
the appropriate separator used when the Path object was passed to, for 
example, open().

To me, a path is an ambiguous item:  /temp/here/xyz.abc
where does the directory structure stop and the filename begin?  xyz.abc 
could be either the last subdirectory, or the filename, and the only way 
to know for sure is to look at the disk.  However, the Path may not be 
complete yet, or the final item may not exist yet -- so what then?  I'm 
refusing the temptation to guess. ;)  The programmer can explicity look, 
or create, appropriately.


> [...] 
>> So, I suppose I shall have to let go of my dreams of
>>
>> --> Path('/some/path/and/file') == '\\some\\path\\and\\file'
> 
> To say nothing of:
> 
> Path('a/b/c/../d') == './a/b/d'

I think I'll make my case-insensitive Paths compare, and hash, as 
all-lowercase, so direct string comparison can still work.  I'll add an 
.eq() method to handle the other fun stuff.


> Why do you think there's no Path object in the standard library? *wink*

Because I can't find one in either 2.7 nor 3.2, and every reference I've 
found has indicated that the other Path contenders were too 
all-encompassing.

~Ethan~