You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Refactor Argument Clinic support code into libclinic #113299
I think it is a really good idea to split clinic.py into multiple files. The C preprocessor stuff is already separated out (cpp.py). We should do this in iterations; not everything in one big PR. Perhaps it is easiest to start with the converters; it's a large chunk of clinic.py, and I think it would be pretty easy to separate it from the rest. Separating out the application is also a good start.
Moreover, doing this work in chunks/iterations, instead of everything in one go, will minimise the impact on ongoing Argument Clinic work.
+1 to splitting clinic.py up, and +1 to doing it incrementally rather than in one big PR.
Previously I've held off from doing something like this because clinic.py's use of global variables means that lots of parts of the file are tightly coupled to other parts in surprising and unfortunate ways. In #113300, warn() and fail() still use a global clinic variable in utils.py, but that variable is now altered from code in other files, making it even harder to understand what's going on. That feels worse, and it feels like we're avoiding solving the actual problem here, which is that clinic.py just shouldn't really be using global variables like this in the first place.
But maybe it's acceptable for now, if splitting the code up into several files is a higher priority :) Getting rid of the global variables is hard!
IMO, getting rid of the global variables should be a prerequisite to splitting things up. We don't need to rush this; clinic.py has been a single file since it started out in life. Argument Clinic is already hard to comprehend, so any refactoring, including splitting up should make it more readable, not the other way around. Readability is IMO the highest priority.
Since last week, we've done a lot of yak-shaving (and there is more to be done). A bare bones libclinic has been established, containing most of the stateless formatting code. The next steps will be to move ClinicError into libclinic/errors.py, and rename cpp.py to libclinic/cpp.py.
Activity
pythongh-113299: Split clinic.py into sub-files
erlend-aasland commentedon Dec 20, 2023
This has also been discussed before. See #104683 (comment).
erlend-aasland commentedon Dec 20, 2023
I think it is a really good idea to split
clinic.pyinto multiple files. The C preprocessor stuff is already separated out (cpp.py). We should do this in iterations; not everything in one big PR. Perhaps it is easiest to start with the converters; it's a large chunk ofclinic.py, and I think it would be pretty easy to separate it from the rest. Separating out the application is also a good start.Moreover, doing this work in chunks/iterations, instead of everything in one go, will minimise the impact on ongoing Argument Clinic work.
AlexWaygood commentedon Dec 20, 2023
+1 to splitting clinic.py up, and +1 to doing it incrementally rather than in one big PR.
Previously I've held off from doing something like this because clinic.py's use of global variables means that lots of parts of the file are tightly coupled to other parts in surprising and unfortunate ways. In #113300,
warn()andfail()still use a globalclinicvariable inutils.py, but that variable is now altered from code in other files, making it even harder to understand what's going on. That feels worse, and it feels like we're avoiding solving the actual problem here, which is that clinic.py just shouldn't really be using global variables like this in the first place.But maybe it's acceptable for now, if splitting the code up into several files is a higher priority :) Getting rid of the global variables is hard!
erlend-aasland commentedon Dec 20, 2023
IMO, getting rid of the global variables should be a prerequisite to splitting things up. We don't need to rush this; clinic.py has been a single file since it started out in life. Argument Clinic is already hard to comprehend, so any refactoring, including splitting up should make it more readable, not the other way around. Readability is IMO the highest priority.
pythongh-113299: Create libclinic package
vstinner commentedon Dec 20, 2023
AlexWaygood commentedon Dec 20, 2023
erlend-aasland commentedon Dec 20, 2023
erlend-aasland commentedon Dec 20, 2023
vstinner commentedon Dec 20, 2023
[-]Argument Clinic: split clinic.py into sub-files[/-][+]Refactor Argument Clinic support code into libclinic[/+]erlend-aasland commentedon Dec 27, 2023
Since last week, we've done a lot of yak-shaving (and there is more to be done). A bare bones libclinic has been established, containing most of the stateless formatting code. The next steps will be to move
ClinicErrorintolibclinic/errors.py, and renamecpp.pytolibclinic/cpp.py.erlend-aasland commentedon Dec 27, 2023
libclinic/errors.pywas established via #113525.pythongh-113299: Move cpp.py into libclinic
gh-113299: Move cpp.py into libclinic (#113526)
pythongh-113299: Move cpp.py into libclinic (python#113526)
pythongh-113299: Move cpp.py into libclinic (python#113526)
erlend-aasland commentedon Apr 3, 2024
Superseded by #113317
pythongh-113299: Move cpp.py into libclinic (python#113526)