[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 :-)



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