On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> >> == a tuple instead of a string ==
> >>
> >> The biggest conceptual change is that my path object is a subclass of
> >> ''tuple'', not a subclass of str.
>
> Why subclass anything? The path should internally represent the filesystem
> path as a list or tuple, but it shouldn't *be* a tuple.
Good point.
> Also, was it a deliberate design decision to make the path objects immutable,
> or was that simply copied from the fact that strings are immutable?
>
> Given that immutability allows the string representation to be calculated once
> and then cached, I'll go with that interpretation.
Immutability also allows them to be dictionary keys. This is
convenient in many applications.
> Similarly, I would separate out the extension to a distinct attribute, as it
> too uses a different separator from the normal path elements ('.' most places,
> but '/' on RISC OS, for example)
That would be too surprising to users. p[-1] should be the full
filename. We can use p.name, p.extsep, and p.ext for the parts.
> Alternatively, if the path elements are stored in separate attributes, there's
> nothing stopping the main object from inheriting from str or unicode the way
> the PEP 355 path object does.
Do the string methods call .__str__(), or how do they get the string value?
> I wouldn't expose stat() - as you say, it's a Unixism. Instead, I'd provide a
> subclass of Path that used lstat instead of stat for symbolic links.
>
> So if I want symbolic links followed, I use the normal Path class. This class
> just generally treat symbolic links as if they were the file pointed to
> (except for the whole not recursing into symlinked subdirectories thing).
>
> The SymbolicPath subclass would treat normal files as usual, but *wouldn't*
> follow symbolic links when stat'ting files (instead, it would stat the
> symlink).
Normally I'd be processing the subdirectories, then the symlinks, off
the same path. I'd rather just call a different method rather than
having to construct another object.
> >> == One Method for Finding Files ==
> >>
> >> (They're actually two, but with exactly the same interface). The
> >> original path object has these methods for finding files:
> >>
> >> {{{
> >> def listdir(self, pattern = None): ...
> >> def dirs(self, pattern = None): ...
> >> def files(self, pattern = None): ...
> >> def walk(self, pattern = None): ...
> >> def walkdirs(self, pattern = None): ...
> >> def walkfiles(self, pattern = None): ...
> >> def glob(self, pattern):
> >> }}}
> >>
> >> I suggest one method that replaces all those:
> >> {{{
> >> def glob(self, pattern='*', topdown=True, onlydirs=False,
> >> onlyfiles=False): ...
> >> }}}
>
> Swiss army methods are even more evil than wide APIs.
I don't see the point in combining these either. There's the problem
of walking special files, but these are so rare and diverse that we
either have to provide methods for all of them, or an argument, or
force the user to use .walk(). Since they are rare, the latter is OK.
> Now, what might potentially be genuinely useful is paired walk methods that
> allowed the following:
>
> # Do path.walk over this directory, and also return the corresponding
> # information for a destination directory (so the dest dir information
> # probably *won't* match that file system
> for src_info, dest_info in src_path.pairedwalk(dest_path):
> src_dirpath, src_subdirs, src_files = src_info
> dest_dirpath, dest_subdirs, dest_files = dest_info
> # Do something useful
>
> # Ditto for path.walkdirs
> for src_dirpath, dest_dirpath in src_path.pairedwalkdirs(dest_path):
> # Do something useful
>
> # Ditto for path.walkfiles
> for src_path, dest_path in src_path.pairedwalkfiles(dest_path):
> src_path.copy_to(dest_path)
These look like os.walk() derivatives. I've never found that as
useful as getting a flat iteration of paths. But if enough people
want it...
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
_______________________________________________
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
