bpo-47152: Convert the re module into a package

[serhiy-storchaka]

https://bugs.python.org/issue47152

[vstinner]

Would it make sense to drop "sre_" prefix of module moved into the re package? re.sre_xxx now sounds redundant to me.

Overall, I like the approach!

Would it make sense to put an underscore prefix to "internal" sub-modules like re.sre_compile? For example, rename it to re._compile. asyncio, email and multiprocessing packages don't attempt to hide sub-modules. I don't know what's the best approach here.

The pip project now puts its whole code into a private pip._interal package: https://github.com/pypa/pip/tree/main/src/pip People used to abuse internals which was too easy to access. Now the "pip" package is a front-end only exposing the public API. In the pyperf project, all sub-modules are prefixed by an underscore: https://github.com/psf/pyperf/tree/main/pyperf In my experience, it was a good idea it since the internal API changed many times and I wanted to make sure that people don't use the internal API but only the public and tested API.

[vstinner]

The gevent has C extensions (sub-modules) in its gevent package namespace. It might be possible to move the _sre extension as re._sre (or a different name), but the Python build system is not really designed for that. And currently, Linux distributions separate .py files and .so files in two separated directories. I suggest to not change that. It's ok to keep _sre as it is. I don't think that moving it is worth the troubles it would create.

[serhiy-storchaka]

It was my initial approach. Look at changes excluding 3da0b4c.

[vstinner]

It was my initial approach. Look at changes excluding 3da0b4c.

If a project currently uses sre_constants, it can use from re import _constants as sre_constants, no? What is the benefits of using keeping the old names?