fotis has quit [Read error: Connection reset by peer]
fotis has joined #pypy
<cfbolz>
pfff, buffers again
<cfbolz>
I'm lost immediately
fotis has quit [Ping timeout: 272 seconds]
<cfbolz>
ronan: do you happen to be around?
<cfbolz>
ronan: (sorry, asking the question in case you read it later): the subclasses of pypy.interpreter.buffer.BufferView correspond to Py_buffer in CPython, right? if yes, there is currently no equivalent to go from a BufferView to the underlying w_obj in pypy, but CPython has Py_buffer.obj. this causes (very indirectly) some problems in the new out of band picklebuffer stuff. any reasons not to add a .w_obj field to BufferView?
fotis has joined #pypy
lritter has joined #pypy
fotis has quit [Ping timeout: 264 seconds]
lritter_ has joined #pypy
lritter has quit [*.net *.split]
fotis has joined #pypy
fotis has quit [Ping timeout: 252 seconds]
fotis has joined #pypy
stkrdknmibalz has quit [Quit: WeeChat 3.0.1]
fotis has quit [Ping timeout: 255 seconds]
<arigato>
cfbolz: fwiw I'm +1 to add .w_obj, set as a best effort when constructing the BufferView instance
<cfbolz>
arigato: ok :-)
<arigato>
I don't think it would have a real cost either in complexity or in performance
<cfbolz>
Just a bit of typing
<cfbolz>
arigato: thanks, that's helpful, will do it
<arigato>
there is no way to access this from pure python?
<arigato>
from a 'memoryview' object or something?
<arigato>
yes, how is the memoryview.obj attribute implemented?
<arigato>
right, in CPython, memoryview(memoryview(b'')).obj returns b''
<arigato>
can't check right now but reading the source code, in pypy3 it would return the inner memoryview instead of b''
<arigato>
ah no there is a special case
<arigato>
my point is that in CPython I think the '.obj' attribute reads from the underlying Py_buffer, whereas in PyPy3 it reads from the memoryview object directly, which might make a difference in more complicated cases
fotis has joined #pypy
<cfbolz>
arigato: yes, that's how I arrived at this
<cfbolz>
Some weird pickle buffer
<cfbolz>
Where, if it makes a memory view it really expects to get the underlying bytes back when reading .obj from python
<cfbolz>
And in PyPy that information is lost
<cfbolz>
Because the SimpleView subclass only has the underlying rpython bytes
mattip has quit [Read error: Connection reset by peer]
mattip has joined #pypy
<cfbolz>
ouch. I tried to look into the asyncio failures. it turns out that they implemented some accelerator function in the _asyncio module in C, and if I disable those cpython fails tests too
<mattip>
so the accelerator functions change behavior?
<cfbolz>
yes
<cfbolz>
they interfere with the testing setup
<cfbolz>
there's a monkeypatching in test_asyncio/util.py
<cfbolz>
that affects only the python implementation
<cfbolz>
but not the C one
<cfbolz>
anyway, seems like a shallow problem
<cfbolz>
should stleep now though
<mattip>
sounds like a cpython bug to me
<cfbolz>
mattip: yes, but probably only in test support code
<mattip>
maybe worth reporting upstream if we figure out how to fix it
<mattip>
just saw that python3.10 will be compiled with gcc flags -fno-semantic-interposition which increases pyperformance benchmarks by 30%