<kenaan>
mattip default 9af25f100cea /lib_pypy/_cffi_ssl/_cffi_src/openssl/evp.py: add more missing API functions that caused HMAC block_size error and test failure
<kenaan>
arigo default f48b6c5fe1ca /: Un-fix the broken attempt at emulating bug-to-bug compatibility, and instead just give the "correct" result in all ...
BPL has joined #pypy
<kenaan>
arigo py3.6 72fdf69a0e6d /pypy/module/cpyext/: issue #3055 fix if we see a PyTypeObject with tp_doc==""
<mattip>
arigato: thanks
<arigato>
ah pff
<arigato>
OK I found the buggy line in CPython
<arigato>
they do ``if (PyInt_Check(key))... else if (key == Py_True)...``
<arigato>
but of course, Py_True passes the test PyInt_Check()
<arigato>
so it's clearly a bug and not a side-effect of some obscure design decision
tsaka_ has joined #pypy
BPL has quit [Read error: Connection reset by peer]
<tos9>
oy
<mattip>
feel like submitting a bug report?
<nimaje>
well, it is a effect of the design decision that bool is a subclass of int
<mattip>
my latest grasping-at-straws theory about the aarch64 translation failures is because the own tests are running in parallel, there is some memory corruption
<tos9>
nimaje: the bool change is intentional but arigato was saying the line of code cannot be functioning as intended -- the person who wrote it was clearly trying to special case bools and just accidentally forgot that the second part of the conditional will never be reached
<tos9>
(and then wrote no unit tests and didn't notice, hooray.)
<wleslie>
pypy development is fantastic at discovering bugs in other people's software
<nimaje>
ah, now I see, it is that json.dumps bug, ok
xcm has quit [Remote host closed the connection]
<mattip>
yesterday I was in a panic because numpy runs pypy in its CI, and on a PR only pypy tests failed. Bug in PyPy? C-API?
<mattip>
it turns out the PR had "if s is 'value': ..."
<mattip>
which works fine on CPython
xcm has joined #pypy
<mattip>
and sometimes works fine on PyPy too, but only when the test was rerun (deleting the pyc files made the test fail)
<kenaan>
mattip buildbot d6d16988b8b9 /bot2/pypybuildbot/builds.py: only allow a single aarch64 build at a time
jcea has joined #pypy
<kenaan>
mattip default 7a38750c11b1 /lib_pypy/_cffi_ssl/_cffi_src/build_openssl.py: force linking against openssl 1.0.2 on win32. CPython changed this for v3.7
<nimaje>
well, but cpythons 'is' isn't '==' for strings, for example https://0x0.st/zVd2.txt
<arigato>
nimaje: the point is that 'is' is ill-defined, and making it be '==' seems to be the only full-definition that makes sense
<arigato>
currently pypy implements this definition of 'is' for most types, except strings-of-more-than-one-character, and non-empty tuples and frozensets
<arigato>
before we implemented all that we have now, we used to have regularly bogus bug reports because people rely on things
<arigato>
not to mention, the example you give will probably produce "true" on pypy after jitting, because the jit figures out it's all the same
<arigato>
or some more complicated variant maybe, like this example would produce "false" but if you run it in a loop then all the "a + b + c" give the same string object (different from abc)
<nimaje>
yeah, for strings 'is' is bad as you normally don't care about object identity there and if you do you probably want to use marker objects instead
ekaologik has quit [Ping timeout: 248 seconds]
Rhy0lite has quit [Quit: Leaving]
Taggnostr3 has joined #pypy
Taggnostr has quit [Ping timeout: 250 seconds]
<cfbolz>
arigato: I am slightly wary of this, because then 'is' wouldn't even be O(1)