Message10444

Another thought: maybe acquiring the module import lock is masking a multithreaded issue?

Let's look at what happens with `import re`:

re.py -> sre_compile.py -> _sre.java, sre_constants.py (which also imports from _sre.java for MAXREPEAT). Except for _sre.java and its supporting Java classes, the remainder are pure Python and these Python modules in all cases except what I mentioned in msg10275, identical source with CPython.

Some things that I note:

* The specific constants that are missing (as reported by ValueError("unsupported operand type", op)) are not seen in the failed compilations in the _compile function in sre_compile.py are defined in pure Python: sre_constants.AT (= "at"), sre_constants.IN (= "in")

* sre_compile._compile function does a conditional import of sre_parse.py.

* constants like sre_constants.IN, etc, are compared using identity with the `is` operator.

So this begs the question: is it possible that a parse of a regex pattern occurs with one set of constants from sre_constants.py, using one version of sre_parse.py; unloading of sre_constants.py occurs; and the compilation is attempted with a reloaded version of sre_constants.py?

This possible interleaving seems to be crazy, but could explain why the module import lock acquistion can help, as seen in The Grinder docs.

One possible way to test whether this is occurring as I suggest is to change lines like the following in sre_compile._compile from, for example:

        elif op is AT:

to

        elif op == AT:

etc.

Users who want to try this out can make the suggested code changes in a test environment and see if this in any way helps.