Closed cjrh closed 1 year ago
Thanks for finding this. The file is generated, so that is what had to be fixed. I have also updated the release procedure in the wiki to make sure the stubtest Makefile rule is run.
no_change is a type at the C API level because that is required for it to have a docstring. It is however a singleton so is given as object
in the type stub.
There still remain 3 errors in the type stubs because mypy doesn't allow a Sequence where the members are different types. I'll have to figure out how to deal with that.
Great, thank you 👍🏼
doesn't allow a Sequence where the members are different types. I'll have to figure out how to deal with that.
FWIW I've run into this. If you know the range of types, you can just make a new type which is a union of the known types, and then declare the var as a sequence of the union type. At least that used to work when I last had this issue.
The C code has comments which are extracted by some tools. That extracted text is then turned into the restructured text built with sphinx for the main doc. It is also processed to make docstrings as C macros so that has docs. And it is processed to do argument parsing in the C code (analagous to argument clinic). Oh and that has two different syntaxes! And the same text is also used to generate the type stubs.
So the difficulty is the same text is serving duty communicating with humans, and several different tools (sphinx, PyArg_ParseTupleAndKeywords, mypy). And this all has to work on Python 3.6 onwards! In general I have prioritised humans.
IIRC Tuple typing does allow each member being a different type, so the fix will probably be along the lines of saying Tuple instead of Sequence,. when technically Sequence is what is correct. Worst case I'll have to make what goes into the type stubs be different than the other places.
I find the stuff at the top of the module doc to be pretty terrible.
This fixes a syntax error in the types stub file. This error turns out to be quite hard to deal with because currently mypy has no good way of excluding a specific third party package (like apsw) from the parsing stage. The only way that works is to use the
--no-site-packages
flag, which excludes all external packages. The--exclude
option does not work for syntax errors during parsing, like this one. In a large project, this error is preventing us from running mypy.This is reproducible in the APSW repo (python 3.11):
The fix seems simple, but I confess it's been a while since I've worked with the C api. The code where the
no_change
is declared looks like this:It's a
PyTypeObject
so that would mean that from Python the superclass would betype
, right? That's what I have in this PR. This allows mypy to continue with the full run, output shown below. Note that I am not focusing on the specific issues raised by mypy in the APSW project: my goal is to fix the unavoidable syntax error during parsing.