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
<graingert>
there's a bug to re-implement the cpython2.7 behaviour but it seems to have stalled ^
<cfbolz>
the usual "eight years of interactions then nothing happens"
<antocuni>
IIRC we have a tool which helps to track which references are keeping alive a certain object
<antocuni>
where is it again?
<graingert>
cfbolz: I added a smaller repro
<graingert>
cfbolz: that's more focussed on the missing call to __subclasscheck__
<cfbolz>
antocuni: gc.get* works, no?
<antocuni>
yes, but I vaguely remember that we had something based on our dotviewer, so you could click interactively on things
<antocuni>
in the meantime I found that objgraph.show_backrefs works well enough
adamholmberg has joined #pypy
adamholmberg has quit [Ping timeout: 265 seconds]
<arigato>
graingert, cfbolz: I can try to fix that issue
<cfbolz>
arigato: cool :-)
<cfbolz>
arigato: I would kind of be tempted to make pypy3 behave like this too
<arigato>
mostly scared that generalizing the logic (to use the variant calling __subclasscheck__) would prove too much
<graingert>
cfbolz: arigato what about a fix for cpython3 at the same time?
<graingert>
Or maybe it would be easier to fix cpython2 to match cpython3 for the April 1st release
<graingert>
s/fix/break/
<arigato>
I'm OK with fixing pypy3 too as long as there is no test in CPython3 checking that it *doesn't* work
<cfbolz>
good question
<graingert>
Would be even better to call isinstance(e, type)
<graingert>
Rather than issubclass(type(e), T)
<cfbolz>
arigato: what do you mean by "prove too much"?
<arigato>
cfbolz: anyway, it will probably work in pypy3 just by the merge, and we can see if it makes a test regress
<graingert>
The exception handling in python is very strange as it passes around a tuple of (instance, type, stack)
<graingert>
And you should be able to get the type from the instance
<arigato>
cfbolz: I meant, is it a good idea to call the completely general logic of the app-level subclass() function, or would that call more things and return True is more cases unexpectedly
<arigato>
graingert: yes, definitely
<cfbolz>
arigato: yes, I agree that it's a bit of a risky modification
<graingert>
Uhh wait you'd need to re-nest that structure
<arigato>
cfbolz: OK it seems that CPython also calls the general logic PyObject_IsSubclass(), which is exactly the one called by __builtin__.subclass()
<cfbolz>
graingert: a lot of it is a holdover from when exceptions were strings
<graingert>
smh
<cfbolz>
python is old
* cfbolz
afk
<arigato>
there's even unclear old code in pypy, too, because we started at the time where CPython (2.4?) was still using old-style classes for exceptions
<cfbolz>
arigato: right!
<arigato>
...no, reading more of the CPython source code, my fix is bogus too
<arigato>
as shown by a failing test in test_raises
<arigato>
cfbolz: in CPython source code was explicitly changed to no longer call PyObject_IsSubclass(), with a comment:
<arigato>
/* PyObject_IsSubclass() can recurse and therefore is
<arigato>
<arigato>
not safe (see test_bad_getattr in test.pickletester). */
<arigato>
so I guess it means they have a test that would fail
<arigato>
I'm going to copy the CPython3 logic for now
<cfbolz>
Even on PyPy2?
<arigato>
no, on PyPy3 only
<arigato>
PyPy2 copies CPython2
<cfbolz>
OK
<cfbolz>
Sounds like a good plan
<cfbolz>
arigato: while you are here: CPython 3.7 has a few new tests around left and right shifting of longs by longs
<cfbolz>
Do I see it correctly that right shifting long by something that doesn't fit into an int will give 0 or -1, due to memory constraints?
<arigato>
uh, what's the python 3 syntax for the two-arguments version of the "raise" keyword?
<arigato>
cfbolz: yes, it gives 0 for x>=0 and -1 for x<0
<cfbolz>
arigato: right
<cfbolz>
arigato: I am not sure there is a two argument version of raise in python3?
<arigato>
cfbolz: seems not. There's still code doing normalization though
<arigato>
a bit unsure how to invoke it now
<cfbolz>
arigato: hm
<cfbolz>
There should only be two cases now, raising a class or an instance
<arigato>
but e.g. using the C API you can still send a separate class and instance
<graingert>
btw the "We’re removing Mercurial support" sits right on top of the submit button for creating issues
xcm has joined #pypy
<graingert>
well not quite there's a 1 pixel hitbox
<graingert>
is there a way to hide it, or do you just make a ublock origin rule?
<arigato>
I have no clue
<arigato>
this annoying "We're removing Mercurial support" appears randomly, it's not appearing for me at the moment
<graingert>
"there are probably tests" I thought we knew there was a test for py3?
<arigato>
there is one, according to a comment in the CPython source
<arigato>
so "probably", because many things may have made that comment invalid
<graingert>
you don't run the cpython3 tests against pypy?
<graingert>
pypy3*
<arigato>
we do, but nightly
<graingert>
ah I see
<graingert>
might be worth kicking off a run with the fix applied and seeing what the test was
<graingert>
then the comment would be most useful
<arigato>
well, I'd have to first enable the fix in pypy3, run the CPython tests (which involves first translating pypy3, a one-hour-long process), etc., only at the end to probably revert that change
<graingert>
arigato: and if there is no test, I can try to add one in cPython
<arigato>
that sounds good from my point of view, but note also that the 8-years-old issue on cpython was about to fix that somehow
lritter has joined #pypy
<arigato>
if you want to know if cpython has a test or not you should start by digging from cpython's comment: it mentions the test name
<graingert>
oh that might make life easier then
<graingert>
always worth getting a "removed one word from a pypy comment" line on the cv
<arigato>
it's a pickling test, which cannot be ported into a quickly-run non-translation test for pypy because the pickling module is very large
<arigato>
and well, honestly nowadays I'm not up to spending hours just to know a complete detail in cpython 3.x
<arigato>
our (probably over-optimistic) policy is "once the cpython issue lands, it will have a test, and we'll see it clearly failing"
<graingert>
Cool
xcm has quit [Read error: Connection reset by peer]
<Dejan>
ronan, thanks for the info about blist
<Dejan>
I will try to see whether I can get rid of it
xcm has joined #pypy
jvesely has joined #pypy
adamholmberg has joined #pypy
Rhy0lite has joined #pypy
<Dejan>
it would be really nice if pypy wheels could be published to pypi repos
<antocuni>
Dejan: yes, that would be the best. However, it depends on the individual projects, we cannot publish official wheels for them
<Dejan>
sure
oberstet has quit [Remote host closed the connection]
adamholmberg has quit [Remote host closed the connection]
adamholmberg has joined #pypy
adamholm_ has joined #pypy
adamholmberg has quit [Read error: Connection reset by peer]
jvesely has quit [Quit: jvesely]
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
jcea has joined #pypy
jcea has quit [Ping timeout: 248 seconds]
micisuta has quit [Ping timeout: 265 seconds]
Smigwell has joined #pypy
seddy has joined #pypy
Ai9zO5AP has joined #pypy
<graingert>
antocuni: someone could make a piwheels for pypy
<mattip>
But as far as pypy goes, i think 32bit pi is not a good fit. Can you convince me why we should invest our limites resources into better supporting it?
<Dejan>
blist sucks ass, pardon my French
mattip has quit [Remote host closed the connection]
<Dejan>
regarding Pi ... I think aarch64 is the future and PyPy is ready for it :)