> I have recently been playing with the fnmatch module, and learned that * > and ? as considered by 'fnmatch.translate()' match *all* characters, > including slashes, colons, backslashes -- in short, whatever happens to > be "special" characters for pathnames on the current platform. > > In other words, "foo?bar.py" matches both "foo_bar.py" and "foo/bar.py". > > This is not the way any Unix shells that I know of work, nor is it how > the wildcard-expanding MS-DOS system calls that I dimly remember from a > decade or so back worked. I dunno how wildcard expansion is done under > Windows nowadays, but I wouldn't expect * and ? to match colons or > backslashes there any more than I expect them to match slash under a > Unix shell. > > So is this a bug or a feature? It's a feature. As I recall, I carefully implemented the standard fnmatch() as it existed 10 years ago. Use the glob module for matching Unix pathname syntax -- or use os.path.split(). I'm not wildly fond of the GNU way of adding 10 more options to each function... KISS. (And yes, I'm in a bad mood today. :-( ) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4