[issue2551053] REST-API: Regular expressions used as keys in dictionary

Ralf Schlatterbeck <[email protected]>
Newsgroups gmane.comp.bug-tracking.roundup.devel
Message-ID <[email protected]>
New submission from Ralf Schlatterbeck:

The __route_map dictionary takes regular expressions as keys of a
dictionary. Now the regular expression implementation (at least in
python2) has a cache, so usually returns the same object for the same
regex (plus options) for calls to re.compile.

But this doesn't seem to work in all cases, we're observing a dictionary
with multiple entries for the *same* regular expression with different
methods in a WSGI process in apache, e.g.

^rest/data/([\\w.\\-~!$&'()*+,;=:\\%%]+)$ ['POST', 'GET']
^rest/data/([\\w.\\-~!$&'()*+,;=:\\%%]+)$ ['OPTIONS', 'DELETE']

(this prints the .pattern of the compiled regex plus the options stored
under that key)

The result is that we sometimes get an error message "Method not
allowed" for a call to PUT (or GET) on a path that should allow this method.

A simple test that bypasses the regex cache (by clearing it between
invocations) shows that compiled regular expression objects should not
be used as keys in a dictionary (at least not in Python2):

>>> import re
>>> r1 = re.compile ('a')
>>> re.purge ()
>>> r2 = re.compile ('a')
>>> r1 == r2
False
>>> d = dict (r1 = r1, r2 = r2)
>>> d
{'r1': <_sre.SRE_Pattern object at 0x7f4a0aa19d78>, 'r2':
<_sre.SRE_Pattern object at 0x7f4a0aa19e00>}

Thanks to Robert Klonner for debugging it so far that I could make this
bug-report. We're working on a fix, too, so no need to look into this
too soon.

----------
assignee: schlatterbeck
messages: 6590
nosy: schlatterbeck
severity: normal
status: new
title: REST-API: Regular expressions used as keys in dictionary

_________________________________________________
Roundup tracker <[email protected]>
<https://issues.roundup-tracker.org/issue2551053>
_________________________________________________
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.