[Python-Dev] Reorganizing re and curses related code
Antoine Pitrou
solipsis at pitrou.net
Fri Nov 3 06:12:56 EDT 2017
Sounds good to me :-)
Regards
Antoine.
On Fri, 3 Nov 2017 12:01:28 +0200
Serhiy Storchaka <storchaka at gmail.com> wrote:
> Currently the implementation of re and curses related modules is sparsed
> over several files:
>
> re:
> Lib/re.py
> Lib/sre_compile.py
> Lib/sre_constants.py
> Lib/sre_parse.py
>
> _sre:
>
> Modules/_sre.c
> Modules/sre_constants.h
> Modules/sre.h
> Modules/sre_lib.h
>
> _curses:
> Include/py_curses.h
> Modules/_cursesmodule.c
> Modules/_curses_panel.c
>
> I want to make the re module a package, and move sre_*.py files into it.
> Maybe later I'll add the sre_optimize.py file for separating
> optimization from parsing and compiling to an internal code. The
> original sre_*.py files will be left for compatibility for long time,
> but they will just import their content from the re package.
>
> _sre implementation will be moved into the Modules/_sre/ directory. This
> will just make them to be in one place and will decrease the number of
> files in the Modules/ directory.
>
> The implementations of the _curses and _curses_panel modules together
> with the common header file will be moved into the Modules/_curses/
> directory. Excluding py_curses.h from the set of global headers will
> increase the speed of rebuilding when modify just the _curses
> implementation (I did this too much recent times). In future the
> implementation of menu and forms extensions will be added (the patch for
> menu has beed provided years ago). Since _cursesmodule.c is one of the
> largest file (it defines hundreds of functions), it may be worth to
> extract the implementation of the _curses.window class into a separate
> file. And I want to implement the support of "soft function-key labels".
> All this will increase the number of _curses related files to 7.
>
> curses already is a package.
>
> Since virtually all changes in these files at recent years have been
> made by me, I don't think this will harm other core developers. Are
> there any objections?
>
More information about the Python-Dev
mailing list