<catern>
somewhat offtopic question, but: cffi lets me generate a Python module from C headers (presumably for an existing C library). does anyone know of anything which lets me generate C headers from Python type stubs? (which would then be implemented by whoever)
<mattip>
catern: the problem is how to map python object to C. The only one that maps nicely is float
<mattip>
int is ambiguous, it can be long or long long or a bigint
<mattip>
cython works around this by using cython object in pure python mode
<catern>
yeah, either making an opinionated decision or requiring extra annotations on the Python stubs would be fine with me - actually you could imagine just using foo: Bigint or foo: LongLong in the Python stubs which just inherit from ints, or something
<catern>
(well, are type aliases for ints, rather)
<catern>
interesting point about cython though, heh, it generates the headers and then also generates the implementation... I doubt it would be suitable to just stop it at generating the headers, but it's interesting...
<arigato>
unsure I see why you want to write Python code and generate an "equivalent" C header, instead of directly writing the C header
<Corbin>
Right, the goal is less C overall and more Python, AIUI.
<catern>
arigato: well - if I write the C header and then generate the Python, I'll get a Python module which is not very idiomatic, which needs to be wrapped; whereas if I write the Python stubs and then generate the C headers, I feel like more of that wrapping work can be done automatically - writing an implementation of the C headers won't be substantially harder if they're generated
<isidentical>
Is it possible to run lib-python tests like applevels with untranslated pypy? (only one specific test, not the whole suite)
<arigato>
isidentical: yes, but it takes a long time (you basically run "pypy/bin/pyinteractive.py lib-python/3/test/test_foo.py")
greedom has quit [Remote host closed the connection]
fotis has joined #pypy
<smarr>
arigato: thanks. I tried adding an assert in places, thought that results in various extra checks and `pypy_g_RPyRaiseException` calls. Still have to look at the assembly and try to make sense of what the compiler does with the C code.
<mattip>
up next: conda-forge patches CPython on windows to move C:\Windows\System32 down in the DLL search path
<mattip>
which apparently will fix the failure in the cryptography feedstock