cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end ) | use cffi for calling C | if a pep adds a mere 25-30 [C-API] functions or so, it's a drop in the ocean (cough) - Armin
<mattip>
maybe you can get some inspiration from that
<mattip>
IMO issue #3429 is not a release blocker, it is an edge case with nonlocal
<mattip>
anyone disagree?
<cfbolz>
FergusL: ah, interesting! I think it should be possible with PyPy. What kind of data do you want to pass back and forth with the process function?
<cfbolz>
mattip: I can try to look into it for an hour today, but I'd understand if you don't want to wait
<mattip>
it should be pretty straightforward, I think a case for missing "free" is lacking in _make_function in pypy/pypy/interpreter/astcompiler/codegen.py
<mattip>
but then I need to run the buildbots again, and who knows what will happen then
<cfbolz>
mattip: fair
holdsworth has quit [Ping timeout: 260 seconds]
holdsworth has joined #pypy
lritter has joined #pypy
Civil has quit [Ping timeout: 248 seconds]
stillinbeta has quit [Ping timeout: 248 seconds]
astrojl_matrix has quit [Ping timeout: 248 seconds]
Civil has joined #pypy
stillinbeta has joined #pypy
astrojl_matrix has joined #pypy
yuiza has quit [Ping timeout: 240 seconds]
yuiza1 has joined #pypy
<FergusL>
mattip thanks. Yes I realize that, the other way is what embedding allows first hand, I still need to figure out the other part, I could go with a hack-ish way if it just works. I'm trying to understand the whole of that: https://cffi.readthedocs.io/en/latest/embedding.html#embedding-and-extending
<FergusL>
cfbolz it would mostly be MIDI messages information. The host application deals with the midi i/o stuff, so the python functions only need like handleNoteMessage(number, velocity, channel) as integers
<FergusL>
actually the CPython implementation with the usual Py_Initialize() interface already exists, I'm just curious experimenting with a faster interpreter and maybe in a simpler way (fwiw it is here, this is a module for the VCV Rack virtual modular software: https://github.com/VCVRack/VCV-Prototype/blob/v1/src/PythonEngine.cpp )
vstinner has joined #pypy
<vstinner>
hi. i proposed to add Py_Is() function to the Python C API, maybe also Py_IsNone(), Py_IsTrue() and Py_IsFalse(): https://bugs.python.org/issue43753
<vstinner>
do you think that PyPy would benefit of C extensions being modified to use Py_Is(x, y) rather than using directly "x == y"?
<vstinner>
HPy requires to call HPy_Is(ctx, x, y), "x == y" raises a compiler error
todda7 has joined #pypy
oberstet has joined #pypy
oberstet has quit [Remote host closed the connection]
oberstet has joined #pypy
<antocuni>
vstinner: as far a pypy/cpyext is concerned, not really. Many existing extensions rely on being able to compare PyObject* with == so we need to support that anyway
<cfbolz>
antocuni: I am not sure that's true
<cfbolz>
I think for pypy this would be good to have
<cfbolz>
because eg int objects behave weird with is
<cfbolz>
it should be corner cases only, but still
<antocuni>
but then we will end up with Py_Is returning different results than == ? That would be even more confusing
<cfbolz>
antocuni: yes, but "a is b" in pypy *does* return different things that a == b in C
<vstinner>
antocuni: Py_Is(x, y) in C should behave exactly as "x is y" in Python
<vstinner>
does PyPy ensure that int+int always return the same PyObject* singleton numbers?
<vstinner>
for example
<vstinner>
i'm not asking to mimick exactly "x is 1" of CPython. that's bad and now raises a SyntaxWarning :-) but well, backward compatibility hits again
<vstinner>
Py_Is() would give more control on how "is" behaves in C
<vstinner>
in CPython longobject.c, all functions go through maybe_small_long() to create a fresh object to a singleton if possible
<antocuni>
yes, I'm just saying that as long as we are in cpyext land we still have to provide full backward compatibility with the existing behavior, so adding new functions doesn't help much
<antocuni>
what would help is to remove == completely, as HPy did :)
<vstinner>
in CPython unicodeobject.c, unicode_result() tries to get empty string and single character singletons if possible
<cfbolz>
antocuni: no, I am arguing that cpyext is currently broken with regards to ==, and cannot be fixed
<cfbolz>
and we just hope that code doesn't care
<vstinner>
how does cpyext handle these singletons?
<vstinner>
CPython has more singletons: empty tuple, empty bytes string, empty frozenset, etc. ;-)
<cfbolz>
yeah, we have them too (but I don't know how cpyext handles them)
<antocuni>
cfbolz: ok, you convinced me
<antocuni>
that said, I double that people will start to use Py_Is anyway
<cfbolz>
think in 5 year cycles ;-)
<antocuni>
s/double/doubt
<antocuni>
cfbolz: my hope is that in 5 years people will use HPy :)
<cfbolz>
me as well
<vstinner>
antocuni: i prefer to solve issues one by one. first add the function, then use it in CPython, later think about how to convince people to use it :)
<vstinner>
antocuni: personally, I prefer to write Py_IsNone(x) than x == Py_None
<cfbolz>
antocuni: but s/Py_Is/HPy_Is" is much easier than with == ;-)
<vstinner>
as I prefer to write "y=Py_NewRef(x);" than "Py_INCREF(x); y=x;", but that's a personal taste ;)
<vstinner>
cfbolz: and add ctx ;)
<vstinner>
antocuni: think about Cython. if i patch Cython to use Py_Is(), 50% of C extensions will suddenly use it ;-)
<vstinner>
cfbolz: you would mind to add a comment at https://bugs.python.org/issue43753 to explain that Py_Is() is required for the interoperability with PyPy, HPy, GraalPython, etc. ?
<LarstiQ>
vstinner: except those extensions also need to start using the new Cython, and this delay can be very real. But I get your point
<vstinner>
LarstiQ: you can expect a delay of 1 year to get C code regenerated when a new release of a project is published on PyPI
<vstinner>
LarstiQ: i know well the delay :) fix cpython, fix Cython, get a Cython release, get a new release of all projects using Cython
<vstinner>
LarstiQ: i'm not working on the short term anyway ;)
<vstinner>
FYI Fedora packages regenerate Cython code when a package is built ;-) we did that since we often got issues on new Python versions
<LarstiQ>
vstinner: right, I know you're working on a long time scale and appreciate your stamina on this problem
<LarstiQ>
should not have taken the 50% at face value, sorry :)
<vstinner>
oh, don't worry, i understood you ;)
oberstet has quit [Remote host closed the connection]
jcea has joined #pypy
oberstet has joined #pypy
fijal has quit [Ping timeout: 260 seconds]
fijal has joined #pypy
yuiza1 has quit [Ping timeout: 246 seconds]
otisolsen70_ has joined #pypy
otisolsen70_ has quit [Remote host closed the connection]