cfbolz changed the topic of #pypy to: PyPy, the flexible snake (IRC logs: https://botbot.me/freenode/pypy/ ) | use cffi for calling C | the secret reason for us trying to get PyPy users: to test the JIT well enough that we're somewhat confident about it
Torgeir has quit [Remote host closed the connection]
Davnit26 has joined #pypy
Davnit26 has quit [Remote host closed the connection]
vok` has joined #pypy
vok` has quit [Remote host closed the connection]
[Arfrever] has quit [Remote host closed the connection]
[Arfrever] has joined #pypy
arigato has joined #pypy
<kenaan>
arigo default 090965df249b /rpython/rlib/rposix.py: Issue 2870 Fix Windows os.listdir() for some cases (see CPython #32539 for the fix and the test that will show up ...
arigato has quit [Quit: Leaving]
moei has quit [Quit: Leaving...]
arigato has joined #pypy
tayfun26 has joined #pypy
tktech29 has joined #pypy
tktech29 has quit [Remote host closed the connection]
udono1 has left #pypy [#pypy]
Madcotto26 has joined #pypy
danchr has joined #pypy
Madcotto26 has quit [Remote host closed the connection]
forgottenone has joined #pypy
Garen_ has joined #pypy
Garen has quit [Read error: Connection reset by peer]
Garen_ has quit [Read error: Connection reset by peer]
Garen has joined #pypy
arigato has quit [Quit: Leaving]
Ragnor4 has joined #pypy
fryguybob has quit [Remote host closed the connection]
moei has joined #pypy
Ragnor4 has quit [Remote host closed the connection]
kenaan has quit [Read error: Connection reset by peer]
bendlas[m] has quit [Read error: Connection reset by peer]
steven18 has joined #pypy
steven18 has quit [Remote host closed the connection]
<cfbolz>
LarstiQ: hm, I suppose cython might have a problem if it turns "is" on integers into == on the C level
<cfbolz>
LarstiQ: in pypy, that is absolutely never safe
<LarstiQ>
cfbolz: other way around, or am I confused?
<cfbolz>
LarstiQ: well, if you implement python-level "is" with a C level == pointer compare, you get confusing results for ints
<cfbolz>
so if cython compiles "is" to "==", that could lead to problems
<LarstiQ>
cfbolz: aaah, "== on the C level", right
* LarstiQ
misparsed
<cfbolz>
np
<cfbolz>
hm, now that I think about it, that's an incompatibility that we can't really fix at all
<cfbolz>
LarstiQ: eg if l is a pointer to a list of ints, then this C snippet would evaluate to False: PySequence_GetItem(l, 0) == PySequence_GetItem(l, 0)
<mattip>
I think that in the case under discussion in gRPC, using `is` was a bug that both cython and cpython knew to work around. We are less forgiving.
<mattip>
so the answer to the_drow is that it is gRPC's fault.
<cfbolz>
mattip: yes, sorry, I was more generally pondering about the problem and got sidetracked
<mattip>
we should teach python linters to warn on use of `is`, unless they are used with True, False, or None
<cfbolz>
well, for objects they can be fine too
<tos9>
probably would need to be a whitelist
<tos9>
int, dict, list, string literals
<cfbolz>
mattip: anyway, in python the problem is solved
<cfbolz>
Because our is does the right thing
<marky1991>
I use is with object() sentinels to see if a kwarg wasn't passed too
<marky1991>
(when None is a valid value thatI need to distinguish)
<cfbolz>
But not with cpyext where people sometimes use == on pyobject*
<the_drow>
wonderful :)
<mattip>
marky1991: we digress, but that sounds like one of the cases I would flag as "needs rethinking".
<mattip>
marky1991: are you sure you cannot give a single default kwarg value?
<marky1991>
any other value is a plausible parameter that the user actually passed
<marky1991>
and i need different behavior if the user didn't pass anything at all
<marky1991>
e.g. if you don't pass this extra arg and you're in this particular flow, the function should raise an exception
<marky1991>
otherwise, so long as they passed something at all (None is fine), proceed
<marky1991>
None is the obvious solution for that kind of sentinel, but that breaks when None is a valid data value
<marky1991>
obviously, in the object() case, I could just as well use ==
<marky1991>
but it feels weird to use == for object() but "is" for None to me anyway. The two should use the same logic imo anyway
<marky1991>
I still wonder why we decided on "is None" personally. But not a subject for #pypy
Kronuz has quit [Ping timeout: 244 seconds]
Kronuz has joined #pypy
forgottenone has quit [Remote host closed the connection]
forgottenone has joined #pypy
adamholm_ has joined #pypy
adamholmberg has quit [Ping timeout: 272 seconds]
tayfun26 has quit [Remote host closed the connection]
marky1991 has quit [Ping timeout: 256 seconds]
marky1991 has joined #pypy
adamholm_ has quit [Read error: Connection reset by peer]
adamholmberg has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
marky1991 has quit [Remote host closed the connection]
marky1991 has joined #pypy
Ks0stm22 has joined #pypy
Ks0stm22 has quit [Remote host closed the connection]
marky1991 has quit [Ping timeout: 240 seconds]
marky1991 has joined #pypy
Kingsy8 has joined #pypy
Kingsy8 has quit [Ping timeout: 260 seconds]
Aprexer has joined #pypy
Aprexer has quit [Remote host closed the connection]
adamholmberg has quit [Remote host closed the connection]
the_drow has quit [Ping timeout: 268 seconds]
adamholmberg has joined #pypy
adamholmberg has quit [Read error: Network is unreachable]
adamholmberg has joined #pypy
Rhy0lite has quit [Quit: Leaving]
forgottenone has quit [Read error: Connection reset by peer]