New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fnmatch to support escape characters #58137
Comments
fnmatch to support escape characters: >>> name = "Document[Ver.2].doc"
>>> pattern = "*\[Ver.2\]*"
>>> fnmatch.fnmatch(name, pattern)
True
that's also fix glob module:
>>> pattern = "ipconfig /\?"
>>> glob.glob(pattern)
"ipconfig /?" |
The doc chapters are entitled "fnmatch — Unix filename pattern matching" and "glob — Unix style pathname pattern expansion". The first explicitly disclaims the feature you request: "Be aware there is no way to quote meta-characters.", suggests using re for anything beyond fnmatch, and shows to use .translate to make a start in doing so. For your example: >>> re.match(r".*\[Ver\.2\].*", "Document[Ver.2].doc")
<_sre.SRE_Match object at 0x000000000331AF38> Indeed, fnmatch works by using translate() and re.match. What you are asking for in something in between the unix language and re. If one re feature is added, why not another? So the scope of these modules is clearly circumscribed. I suspect their intent was to make it easy to translate unix shell scripts into Python. Not obvious from the doc is that an unmatch '[' or ']' is escaped:
>>> name = "Document[Ver.2.doc"
>>> pattern = "*[Ver.2*"
>>> fnmatch.fnmatch(name, pattern)
True
>>> name = "DocumentVer.2].doc"
>>> pattern = "*Ver.2]*"
>>> fnmatch.fnmatch(name, pattern)
True
I presume this matches the *nix behavior, but don't know. |
This reads like a warning to me, i.e. a potential future feature, not a design choice.
When we use glob patterns in our shells, the shell language lets us escape what would otherwise be special characters. Python would be nicer to let us do the same. |
If indeed fnmatch does not match current shells, then I would agree that it should. It looks to me so easy to add that I though it must be a deliberate decision to exclude. In translate: Changing the meaning of '\' from ordinary character to escape char will break any code that depends on its current ordinariness.
>>> fn.fnmatch(r'\x', r'\?')
True # for x any 'ordinary' char, but not is '\?' means "match '?'. This was another reason I closed, although I forgot to mention it. I suppose a new parameter 'escape = False' could be added to all 4 exposed functions to preserve back compatibility. Anyway, I have reopened for further discussion and specification. |
bpo-8402 has discussion and patch(es). |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: