Hi all --
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?
Seems to me that a good fix would be to extend 'fnmatch.translate()' to
have some (maybe all?) of the flags that the standard Unix library
'fnmatch()' supports. The flag in question here is FNM_PATHNAME, which
is described in the Solaris manual as
FNM_PATHNAME If set, a slash (/) character
in string will be explicitly
matched by a slash in pattern;
it will not be matched by
either the asterisk (*) or
question-mark (?) special
characters, nor by a bracket
([]) expression.
If not set, the slash charac-
ter is treated as an ordinary
character.
and in the GNU/Linux manual as
FNM_PATHNAME
If this flag is set, match a slash in string only
with a slash in pattern and not, for example, with
a [] - sequence containing a slash.
To adapt this to Python's 'fnmatch.translate()', I think "slash" would
have to be generalized to "special character", which is platform
dependent:
Unix /
DOS/Windows : \ (and maybe / too?)
Mac :
I propose changing the signature of 'fnmatch.translate()' from
def translate(pat)
to at least
def translate(pat,pathname=0)
and possibly to
def translate(pat,
pathname=0,
noescape=0,
period=0,
leading_dir=0,
casefold=0)
which follows the lead of GNU 'fnmatch()'. (Solaris 'fnmatch()' only
supports the PATHNAME, NOESCAPE, and PERIOD flags; the GNU man page says
LEADING_DIR and CASEFOLD are GNU extensions. I like GNU extensions.)
Similar optional parameters would be added to 'fnmatch()' and
'fnmatchcase()', possibly dropping the 'casefold' argument since it's
covered by which function you're calling.
I have yet to fully grok the meaning of those other four flags, though,
so I'm not sure how easy it would be to hack them into
'fnmatch.translate()'.
Opinions?
Greg
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