path module

holger krekel pyth at
Tue Jul 8 20:28:52 CEST 2003

Ian Bicking wrote:
> On Tue, 2003-07-08 at 04:32, holger krekel wrote:
> > I agree that something like Jason Orendorff's path module should go into
> > the standard library.  I've coded a similar module and i think that
> > a discussion about certain design decisions would probably improve our
> > approaches. 
> > 
> > For example Jason lets the "path" object inherit from "str" (or unicode)
> > but i think it's better to provide a "__str__" method so that you can say
> > 
> >     str(pathinstance).endswith('.py')
> > 
> > and *not* base the path object on str/unicode. 
> > 
> >     unicode(pathinstance)
> > 
> > would just fail if your platform doesn't support this.  First, i tried
> > the inheritance approach, btw, but it is ambigous (e.g. for the
> > join-method (str.join and os.path.join).  
> I'm starting to think the same thing.  Not so much because of join, but
> because it doesn't actually offer many advantages.  Many methods that
> look for a filename will be using "type(arg) is type('')", so you'd have
> to pass a real string object in anyway -- and people who say "but you
> should use isinstance(arg, str)" are obviously forgetting that you
> couldn't do this not very long ago, and lots of code uses type
> comparison at this point.

right.  Also i prefer my objects to not have a "polluted" namespace. 

> > Also, my module provides most of the os.path.* methods as "filters" so
> > you can say
> > 
> >     dirs = filter(isdir, list_obj_pathobjects)
> >     fnames = filter(AND(nolink, isfile), list_obj_pathobjects)
> > 
> > in addition to
> > 
> >     pathobject.isfile()
> >     etc.
> That's not necessary with list comprehension, since you can just do:
> [p for p in list_obj_pathobjects if p.isdir()]

but i use the same idea (filter-functions) for more advanced walkers:

    p = path('/music')
    for i in p.filterwalk(AND(nolink, isfile, isplayable, match(repattern))):

where filterwalk is a generator because i don't want the playscript to 
first try to gather *all* files for obvious reasons (as would happen with 
list comprehension).  This has proven to be incredibly useful and easy to
read (if you don't engange in list-comprehension <-> functional-style
wars).  Just because Guido somewhat dislikes "functional support" like
lambda, map, filter and friends to be in the __builtin__ module 
doesn't mean it's bad :-)



More information about the Python-list mailing list