cfbolz changed the topic of #pypy to: #pypy PyPy, the flexible snake https://pypy.org | IRC logs: https://quodlibet.duckdns.org/irc/pypy/latest.log.html#irc-end and https://libera.irclog.whitequark.org/pypy | the pypy angle is to shrug and copy the implementation of CPython as closely as possible, and staying out of design decisions
LarstiQ has quit [Ping timeout: 256 seconds]
LarstiQ has joined #pypy
jcea has quit [Remote host closed the connection]
jcea has joined #pypy
[Arfrever] has quit [Ping timeout: 245 seconds]
[Arfrever] has joined #pypy
jcea has quit [Ping timeout: 240 seconds]
jinsun_ has joined #pypy
jinsun is now known as Guest225
Guest225 has quit [Killed (cadmium.libera.chat (Nickname regained by services))]
jinsun_ is now known as jinsun
jcea has joined #pypy
<mjacob> cfbolz: I was just reading your excellent blog post about the GC bug. I also observed many times that there were issues because something was created under some set of assumption and re-used where these assumptions were not met. (I’m thinking not only of code but also of more general contexts, although it’s probably easier to focus the discussion on code.) One possible mitigation for this problem, which
<mjacob> we use at work, is to write code to have less assumptions (which I’m a bit skeptical about, as it can be in conflict with the YAGNI principle) and to make the assumptions explicit (which I like a lot). I would be interested in what you think about this approach.
<cfbolz> mjacob: that sounds like an excellent approach if you can pull it off
<cfbolz> my real lesson from the bug, however, is: fuzz all the things
<xorAxAx> static code analysis *duck*
<xorAxAx> .oO(dependant types for RPy)