Document exceptions raised by fnmtach

[DimitriPapadopoulos]

BPO	45815
Nosy	@ezio-melotti, @DimitriPapadopoulos
Files	sre_constants.error_stderr.txt: Last part of the stderr output of a Python script that calls fnmatch() on a bad glob

^{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:

assignee = None
closed_at = None
created_at = <Date 2021-11-16.10:46:44.748>
labels = ['expert-regex', '3.11', 'library', 'docs']
title = 'Document exceptions raised by fnmtach'
updated_at = <Date 2021-11-16.10:46:44.748>
user = 'https://github.com/DimitriPapadopoulos'

bugs.python.org fields:

activity = <Date 2021-11-16.10:46:44.748>
actor = 'DimitriPapadopoulosOrfanos'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Library (Lib)', 'Regular Expressions']
creation = <Date 2021-11-16.10:46:44.748>
creator = 'DimitriPapadopoulosOrfanos'
dependencies = []
files = ['50442']
hgrepos = []
issue_num = 45815
keywords = []
message_count = 1.0
messages = ['406396']
nosy_count = 4.0
nosy_names = ['ezio.melotti', 'mrabarnett', 'docs@python', 'DimitriPapadopoulosOrfanos']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue45815'
versions = ['Python 3.11']

[DimitriPapadopoulos]

The fnmatch documentation should explicitly mention the type of exceptions raised by fnmatch.fnmatch():
https://docs.python.org/3/library/fnmatch.html

In my case it raised sre_constants.error, and it took some time to understand that the proper way to catch this type of exceptions is to catch the re.error superclass, by reading https://bugs.python.org/issue795379.

Actually that would be the case for any module using the re module under the hood, possibly passing an ill-formed regex to a re function.

[gpshead]

It'd also be reasonable for the fnmatch._compile_pattern function to be updated to catch re.error and internally and reraise ValueError. The only times this should happen are when the input pattern turns into an invalid regular expression so our code cannot use it. So in absense of us improving fnmatch's abilities, it is an error with the user supplied value.

Or for maximum backwards compatibility, an fnmatch.PatternError class that inherits from both re.error and ValueError so that code can be written to catch either.

[serhiy-storchaka]

In what case it raises re.error?