Repository navigation
Derby #16: Convert 50 sites to Argument Clinic across 9 files #64383
Description
Activity
This issue is part of the Great Argument Clinic Conversion Derby,
where we're trying to convert as much of Python 3.4 to use
Argument Clinic as we can before Release Candidate 1 on January 19.This issue asks you to change the following bundle of files:
Modules/faulthandler.c: 7 sites
Modules/_pickle.c: 7 sites
Modules/_lzmamodule.c: 7 sites
Python/bltinmodule.c: 6 sites
Modules/termios.c: 6 sites
Modules/syslogmodule.c: 6 sites
Modules/_dbmmodule.c: 4 sites
Modules/_gdbmmodule.c: 2 sites
Modules/_json.c: 5 sitesTalk to me (larry) if you only want to attack part of a bundle.
For instructions on how to convert a function to work with Argument
Clinic, read the "howto":
http://docs.python.org/dev/howto/clinic.html- addedextension-modulesC modules in the Modules dirC modules in the Modules dirtype-featureA feature request or enhancementA feature request or enhancement
on Jan 8, 2014 I'm going to specifically tackle the "bltinmodule" side of things using a test driven approach: adding a new test to test_inspect that checks all the builtin names have signatures (I'll explicitly exclude ones that are known not to be handled, like range and slice).
Attached patch shows the new test case I'm using to ensure that all callable builtins have signatures, and once we get it that way, it stays that way.
Preliminary goal is signatures for all the non-type objects, and once I get to that point, I'll propose it for review.
More comprehensive patch uploaded - all the non-type callables implemented in bltinmodule.c have been converted or classified with a reason for not being converted yet (see the new test in test_inspect.py for details, as well as the AC 3.4 and AC 3.5 comments in the module itself).
I also cleaned up the docstrings for the builtins I actually changed in the patch. There were a few that had never been properly updated for the Py3k transition.
There are still a couple of test failures with this version - the doctest tests get confused by the fact ord and chr now have a doctest in their docstrings, and test_gdb is definitely not in a happy place (that has always been temperamental, though).
I also just realised the Unicode character in the new ord and chr docstrings could pose a compatibility problem at the C compiler source encoding level, so we may have to reconsider that (even though I was rather happy to sneak that obscure Monty Python reference in there).
Assigning to myself to make it clear that bltinmodule is the only part of this still under consideration for 3.4.
The test_pydoc and test_gdb failures pointed to real issues with the previous patch:
-
the pydoc errors themselves were incidental, indicating that I had added doctests to chr and ord. However, those new doctests used a Unicode character in a C string, which seems like a recipe for portability trouble. I took those doctests out again, and updated the prose docs instead. I like my obscure multilingual Monty Python reference and would like to keep it now I thought of it :)
-
the gdb error suggests that gdb is relying on being able to find builtin_id based on its exact signature, including the parameter names. Rather than trying to figure out the full details of that, I've instead partially reverted its conversion to Argument Clinic by disabling the input block and restoring the old parameter names in the function signature. We can change it back to full conversion for 3.5, after AC has the ability to use different names in the Python signature and in the C implementation function.
This does mean we'll want to update the signature by hand once you merge the patch changing the indicators that argument clinic is looking for.
-
Larry, if this version looks good to you, I'd like to commit it.
-
id() is now back to being a properly generated AC function (since AC can now preserve the old C level signature)
-
sorted() is partially converted and has a __text_signature__ compatible docstring. However, full conversion will have to wait for the ability to preserve the kwds dict, since that's the API exposed by the list object.
-
with the new never-triggered-by-accident AC syntax, the test case now ensures that all the builtins that are expected to *not* expose signature info at this point, don't. As they're converted for 3.5, that will force them to be added to the list of functions that are checked for compatibility.
I'm thinking it's probably worth flagging this new test as a CPython implementation detail test, though.
-
Larry, I'd like to include the most-builtin-functions signature support for 3.4, but since the AC Derby is over, it's your call as release manager.
If it looks good to you, go ahead and commit it (I won't have time until later in the week), otherwise just drop the priority and punt it to 3.5.
Interpreting the lack of response as "this can wait until 3.5".
8 remaining items
Proposed patch converts _dbm and _gdbm modules to Argument Clinic.
The patch updated to the tip.
New changeset 49910ff21ba5 by Serhiy Storchaka in branch 'default':
Issue bpo-20184: Converted _dbm and _gdbm modules to Argument Clinic.
https://hg.python.org/cpython/rev/49910ff21ba5Here is a patch that converts 3 functions in the _json module to Argument Clinic. All other functions doesn't fit with Argument Clinic.
Looks like
builtins.varsandbuiltins.dirshould be migrated to AC too, so I create PR18512.Is this metaissue still relevant after nine years? Currently, conversions into AC are handled in smaller, more specific issues so it could be closed.
BTW, the derby has a few more parts:
- Derby #5: Convert 50 sites to Argument Clinic across 3 files #64373
- Derby #8: Convert 28 sites to Argument Clinic across 2 files #64376
- Derby #9: Convert 52 sites to Argument Clinic across 11 files #64377
- Derby #14: Convert 41 sites to Argument Clinic across 5 files #64382
- Derby #16: Convert 50 sites to Argument Clinic across 9 files #64383
- Derby #18: Convert 31 sites to Argument Clinic across 23 files #64385
It looks to me like all of these derby issues would be better closed. Even if some functions do remain unconverted, it's much more likely at this point that they will be converted because someone notices the unconverted function in the codebase, not because of a derby issue with non-descriptive (and almost certainly now obsolete) name that requires digging through all of the listed modules to see if there's any work remaining to be done on it.
As the derby issues say, it was an effort to convert as much as possible before Python 3.4 release. Python 3.4 is long ago released, so the derby is over.
Reacted by Erlend E. Aasland and Irit KatrielWill leave this open for a bit to see if a core dev agrees before closing all of them.
Will leave this open for a bit to see if a core dev agrees before closing all of them.
It's been open for long enough now.
Reacted by Carl Meyer and Hai Shi
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: