Refactor - remove re._compile?

[wimglenn]

Feature or enhancement

Proposal:

Here is re.compile:

>>> import re, inspect
>>> print(inspect.getsource(re.compile))
def compile(pattern, flags=0):
    "Compile a regular expression pattern, returning a Pattern object."
    return _compile(pattern, flags)

It just calls re._compile with the same arguments.

When it was introduced it looked like there was some benefit to having an "implementation hook" to swap in impl from sre_compile.py.

I think the benefit doesn't really exist anymore - it seems like there should be a slight performance improvement, and simpler tracebacks, to just move the body of _compile directly into compile.

Linked PRs

• gh-122358: Remove re._compile #122357

[serhiy-storchaka]

This is a breaking change.

• It breaks pickles. re._compile is used to represent compiled regular expressions. In Pickling compiled re patterns #66606 I proposed to start using re.compile instead, so many years later we could remove re._compile with less hassle, but this idea was not supported. Even if we reopen an implement that issue, we will need to wait 6 or more years before removing re._compile (more is better).
• It breaks warnings. Currently, because re.compile() and all module-level functions that implicitly compile regular expression call _compile(), they all are at the same distance from the source of the warning, so using correct stackleve the warning can point at the right line in the user code that uses these functions. If remove re._compile, they were at different levels, and the code that emits warning cannot know what stacklevel value to use.

[wimglenn]

Hi Serhiy -

1. isn't adequately resolved by leaving the compatibility alias in module namespace as the linked PR shows? I am not proposing to remove it from the module, just from the call stack. The alias can stay around indefinitely.
2. Is an interesting point that I hadn't considered. I'll look for usages of a warning stacklevel within re.compile's call stack which could be affected here and add test coverage for them.

[serhiy-storchaka]

I already added new tests.

In any case the simplest way to solve these issues -- to not remove re._compile.

[wimglenn]

Thanks for doing that! Why didn't reducing the stacklevel by one work to make those warning tests passing again? What am I missing? Had a chance to look into this, it's because of one code path going through re.compile directly and one through re.findall. So the warning will need to know somehow, we can no longer use a constant stacklevel - I'll look into it.

[wimglenn]

@serhiy-storchaka Tests are passing now. It looks as though we could lose the "nested" and "first" arguments in _parse and _parse_sub, they didn't seem to be used for anything significant apart from the warnings. What do you think, is it worth looking into some simplification there?