PRE-PEP: new Path class

[Mike C. Fletcher]

John Roth wrote:
...

>1) Should path be a subclass of str?
>
>No. Outside of the difficulty of deciding whether it's a
>subclass of single byte or unicode strings, it's a pure
>and simple case of Feature Envy. Granted, there will
>be times a developer wants to use string methods, but
>the most common operations should be supported directly.
>  
>
It's not the methods that make me want to use str/unicode as the base, 
it's the ability to pass the resulting instances to built-in methods 
that explicitly expect/require str/unicode types.  Not sure how many of 
the core functions/libraries still have such requirements, but I'd guess 
it's a few.

That said, I don't mind making path it's own base-class, I just *really* 
want to be able to pass them to path-unaware code without extra coercian 
(otherwise switching a module to *producing* paths instead of raw 
strings will cause the *clients* of that module to break, which is a 
serious problem for rapid adoption).

>3) Should the / operator map joinpath.
>  
>
Agreed, no.  As for using + for join, that will break a lot of code that 
does things like this:

    p = mymodule.getSomeFilename()
    backup = p + '.bak'
    copyfile( p, backup )
    open( p, 'w').write( whatever )

i.e. we're thinking of returning these things in a lot of situations 
where strings were previously returned, string-like operations should 
IMO, be the norm.  But then we disagree on that anyway ;) .

>4) Should path expose an iterator for listdir(?)
>
>I don't see why not, as long as the path is to a
>directory.
>  
>
Seems ambiguous to me.  Also seems silly to use a generator when we're 
producing a list anyway from the underlying call, might as well return 
the list to allow length checks and random access.  Iterators for 
"ancestors" might be useful, but again, doesn't really seem like it 
needs to be __iter__ instead of "ancestors".

>5) Should == operator be the same as os.path.samefile()?
>
>Why not...
>  
>
__eq__ sounds about right.  I gather this call goes out to the 
filesystem first, though.  Might be good to first check for absolute 
equality (i.e. the same actual path) before doing that.

>6) Path.open()?
>
>Of course.
>  
>
Ditto.

>7) Should the various gettime methods return Datetime
>objects.
>
>Of course.
>  
>
What are we doing for Python 2.2 then?  I agree with the principle, but 
we should likely have a fallback when datetime isn't available.

>8) Touch method?
>
>Of course.
>  
>
Neutral, seems fine.

>9) Current OS constants?
>
>What are they? Are we talking about the four
>constants in the access() function, or about something
>else?
>  
>
Don't know myself.

>10) Commonprefix, walk and sameopenfile?
>
>Commonprefix should be a string or list method,
>it doesn't fit here.
>  
>
Path commonprefix are different operations from str commonprefix.  Paths 
should only accept entire path-segments (names) as being equal, while 
strings should accept any set of characters:

    '/this/that/those/them'
    '/this/thatly/those/them'

should see '/this/' as the commonprefix for the paths, not '/this/that'.

>walk is a nice function, but it should be redone to
>use the visitor pattern directly, with different method
>names for files, directories and whatever else a
>particular file system has in it's warped little mind.
>  
>
Reworking walk is probably a good idea.  I'll let others worry about it, 
as I've re-implemented the functionality so many times for my own code 
that I'm just sick of it :) .

>11) rename join and split.
>
>I wouldn't bother. Since I'm against making it a
>subclass of str(), the issue doesn't arise.
>  
>
No real preference one way or another here.  join -> "append" for paths 
seems fine.  split -> "elements" or "steps" for paths also seems fine.

>12) Should == compare file sizes.
>
>No. Might have a method to do that.
>  
>
Agreed, though even then, if we have a method that returns file-sizes:

    path( ... ).size() == path( ... ).size()

seems almost as reasonable as having a method for it?

>13) chdir, chmod, etc?
>
>No. This has nothing to do with pathname.
>  
>
chmod has to do with altering the access mode of a file/directory by 
specifying it's path, no?  Seems like it could readily be a method of 
the path.  chdir should accept a path, otherwise doesn't seem like it 
should be a method.

>14. Unicode filenames
>
>Have to have them on Windows and probably
>on the Mac.
>  
>
Yes.

>15. Should files and directories be the same
>class.
>  
>
Replied to this in the sub-thread...

Enjoy all,
Mike

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/