Yuval Greenfield <ubershme...@gmail.com> added the comment:
Thanks for the bug find Antoine, I worked surprisingly hard trying to make this
right in more edge cases and while fixing it I noticed rglob/globtree has 3
options:
* Behave like a glob for every subdirectory. Meaning that every relative path
gets a '*/' prepended to it. Eg rglob('c/d') started from the directory 'a'
will yield 'a/b/c/d'.
* Behave like a glob for every subdirectory of the directory in the filter
string. Meaning rglob('c/d') from dir 'a' won't yield 'a/b/c/d'. It would try
to walk from 'a/c' and yield nothing if the directory 'c' doesn't exist in 'a'.
Note that if the directory 'c' does exist then '/a/c/f/d' would be yielded.
That seems kind of quirky to me.
* Behave like a filtered walk. Meaning that in order to yield files nested in
subdirectories a wildcard must be introduced. Eg rglob('c/d') started from the
directory 'a' won't yield 'a/b/c/d'. For that to occur you would need to use
rglob('*c/d') or rglob('*/c/d'). What's more unfortunate is that rglob('d')
doesn't yield 'a/b/c/d' which seems wrong. So I think for this we should
special case paths that don't have path separators and prepend the "*/". Though
some may argue it's wrong that rglob('d') yields 'a/b/c/d' even though
rglob('c/d') won't yield it, I think that's the correct choice for this route.
Note that absolute paths with/without wildcards don't have this ambiguity. In
both rel/abs wildcards should match directories and files alike.
Which option do you guys think would be best? I already have a fixed patch for
option 1 and 3 but I'd rather hear your thoughts before I introduce either.
P.s. another slight issue I ran into is the fact that fnmatch doesn't ignore
os.curdir:
>>> fnmatch.fnmatch('./a', 'a')
False
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13968>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
