path module
holger krekel
pyth at devel.trillke.net
Tue Jul 8 14:28:52 EDT 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))):
play_mp3(i)
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 :-)
cheers,
holger
More information about the Python-list
mailing list