Repository navigation
Derby #18: Convert 31 sites to Argument Clinic across 23 files #64385
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:
Objects/tupleobject.c: 2 sites
Objects/memoryobject.c: 2 sites
Objects/descrobject.c: 2 sites
Objects/complexobject.c: 2 sites
Modules/_operator.c: 2 sites
Modules/_opcode.c: 2 sites
Modules/_lsprof.c: 2 sites
Modules/_heapqmodule.c: 2 sites
Objects/weakrefobject.c: 1 sites
Objects/structseq.c: 1 sites
Objects/rangeobject.c: 1 sites
Objects/object.c: 1 sites
Objects/moduleobject.c: 1 sites
Objects/funcobject.c: 1 sites
Objects/fileobject.c: 1 sites
Objects/enumobject.c: 1 sites
Objects/codeobject.c: 1 sites
Objects/boolobject.c: 1 sites
Modules/symtablemodule.c: 1 sites
Modules/mathmodule.c: 1 sites
Modules/_tracemalloc.c: 1 sites
Modules/_io/_iomodule.c: 1 sites
Modules/_csv.c: 1 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.htmlLooking at _csv.c, I see a few functions using PyArg_UnpackTuple. They should be converted too, no?
Attached part 1 of mathmodule (17 functions).
I'm looking forward to a suggestion for handling the rest (see FUNC1/1A/2 macros :)
Wow. I never knew about PyArg_UnpackTuple. You're right, those should be converted too. Hooray, more entry points to convert.
I'll write something up for the howto about UnpackTuple.
I just did a quick check, and there are 96 entry points (by my count) that use PyArg_UnpackTuple(). Shall I create Derby issues #19 and #20, or do you have a better idea?
- For FUNC1 / 1A / 2 macros: right now you'd have to just copy and paste over and over. There might be something you could do with a [python] block where you automatedly reuse the existing sigantures. I was thinking about having Clinic support it directly, maybe with the syntax:
/*[clinic input]
func_name = existing_func_namedocstring goes here
[...]*/You'd skip the parameters and the return annotation. You could only reuse functions from the current file. Would that be a big boon to you?
Wow. I never knew about PyArg_UnpackTuple. You're right, those
should be converted too. Hooray, more entry points to convert.
I'll write something up for the howto about UnpackTuple.One thing to note is that (at least in math) many instances of UnpackTuple could have been replaced by ParseTuple. See for example math_hypot: it uses UnpackTuple to get two objects, and then immediately calls PyFloat_AsDouble on them. I've converted these using 'd' and not 'O' specifiers.
I just did a quick check, and there are 96 entry points (by my count)
that use PyArg_UnpackTuple(). Shall I create Derby issues #19 and
#20, or do you have a better idea?Probably better to add them to the issues that cover their modules, otherwise people might get confused.
- For FUNC1 / 1A / 2 macros: right now you'd have to just copy and
paste over and over. There might be something you could do with a
[python] block where you automatedly reuse the existing sigantures.
I was thinking about having Clinic support it directly, maybe with
the syntax:
/*[clinic input]
func_name = existing_func_namedocstring goes here
[...]*/You'd skip the parameters and the return annotation. You could only
reuse functions from the current file. Would that be a big boon to you?That sounds good.
On the other hand, if clinic expanded cpp macros we could... *:-)
- For FUNC1 / 1A / 2 macros: right now you'd have to just copy and
OK, here's a patch for _csv. Two problems here:
First problem is the __new__ method of the Dialect class:
- it has no docstring and no methoddef entry
- it is a class method, but the first arg is conventionally called "type"
I tried to hack something into clinic with a new decorator, but it may not be how you want it to look, take care.
Second problem is the functions reader(), writer(), register_dialect(): they parse their *args but pass their **kwargs through to another class.
Is there anything like a "**kwds" argument specifier?BTW, for a module like _csv that is exported through a Python module named csv, should we use the "real" or the "nice" module name?
Tried to tackle symtable -- it uses an O& converter. The clinic howto says
'O&'object(converter='name_of_c_function')but
Traceback (most recent call last): File "Tools/clinic/clinic.py", line 2817, in <module> sys.exit(main(sys.argv[1:])) File "Tools/clinic/clinic.py", line 2813, in main parse_file(filename, output=ns.output, verify=not ns.force) File "Tools/clinic/clinic.py", line 1116, in parse_file cooked = clinic.parse(raw) File "Tools/clinic/clinic.py", line 1066, in parse parser.parse(block) File "Tools/clinic/clinic.py", line 2109, in parse self.state(line) File "Tools/clinic/clinic.py", line 2378, in state_parameter converter = dict[name](parameter_name, self.function, value, **kwargs) File "Tools/clinic/clinic.py", line 1403, in __init__ self.converter_init(**kwargs) TypeError: converter_init() got an unexpected keyword argument 'converter'
_tracemalloc converted.
Its existing docstrings did use the
func(arg: argtype) -> rettype
convention. Is there a way in clinic to retain that?
Here's _iomodule. _io.open has a whopping 100-line docstring, which is ... unfortunate ... to have duplicated in the file :)
And _heapq. No problems there, except that it also used "->" return annotations in the docstring.
And lsprof.
OK, new patches coming in.
Actually I put all I have in one. Rietveld doesn't care.
The mathmodule still awaits some kind of solution for the macro atrocities.
Objects will be attacked next.
34 remaining items
Argument Clinic generates incorrect parsing code for _csv.field_size_limit().
The problem with lsprof_clinic.patch is that it exposes default value of _lsprof.Profiler.enable() parameters as -1. Actually _lsprof.Profiler.enable() should accept boolean arguments without default value.
python-dev commented
on Feb 4, 2017 python-devmannequinMannequinNew changeset 7f8a3eb3459e by Serhiy Storchaka in branch 'default':
Issue bpo-20186: Converted the symtable module to Argument Clinic.
https://hg.python.org/cpython/rev/7f8a3eb3459epython-dev commented
on Feb 4, 2017 python-devmannequinMannequinNew changeset e1df73b46094 by Serhiy Storchaka in branch 'default':
Issue bpo-20186: Converted the tracemalloc module to Argument Clinic.
https://hg.python.org/cpython/rev/e1df73b46094python-dev commented
on Feb 4, 2017 python-devmannequinMannequinNew changeset b0ef37ec83f337b4b77275b367288a5656a0682c by Serhiy Storchaka in branch 'master':
Issue bpo-20186: Converted the symtable module to Argument Clinic.
b0ef37eNew changeset 18a02e9d1f8e981b7b2f4287a4ed871021b13ade by Serhiy Storchaka in branch 'master':
Issue bpo-20186: Converted the tracemalloc module to Argument Clinic.
18a02e9python-dev commented
on Feb 5, 2017 python-devmannequinMannequinNew changeset 8ccb3ad39ee4 by Serhiy Storchaka in branch 'default':
Issue bpo-20186: Regenerated Argument Clinic.
https://hg.python.org/cpython/rev/8ccb3ad39ee4- added a commit that references this issue
on Oct 6, 2022 - added a commit that references this issue
on Oct 11, 2022 - added a commit that references this issue
on May 20, 2024
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: