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
epsilonKNOT has quit [Read error: Connection reset by peer]
epsilonKNOT has joined #pypy
jcea has quit [Ping timeout: 244 seconds]
danchr has quit [Ping timeout: 256 seconds]
Cheery has quit [Ping timeout: 256 seconds]
danchr_ has joined #pypy
Cheery has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
<mattip> tumbleweed: I think I narrowed it down to an extra JUMP_ABSOLUTE in PyPy3.6-7.3.3 vs. CPython36
<mattip> now where is that being emitted?
<mattip> a direct comparison to cpython's compile.c shows where the problem is, if I understand correctly
<mattip> I wonder what problems still exist in py3.7
tos9 has quit [Ping timeout: 256 seconds]
tos9 has joined #pypy
jacob22 has quit [Read error: Connection reset by peer]
jacob22 has joined #pypy
todda7 has joined #pypy
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
pmp-p has joined #pypy
oberstet has joined #pypy
<cfbolz> mattip: sre, still. arigato, did you get anywhere with that?
<mattip> cfbolz: my intention above was only to the "async for else" problem in issue 3339
<mattip> but yes, indeed, sre is still not done
<cfbolz> mattip: ah, sorry
nascheme has quit [Ping timeout: 240 seconds]
nas has joined #pypy
<mattip> it seems there are tests for async in interpreter/astcompiler/test/test_compiler, but I don't see how they would have caught 3339
<mattip> some of the more obscure tests could use a few more comments saying what they do
Dejan has quit [Read error: Connection reset by peer]
pmp-p has quit [Remote host closed the connection]
pmp-p has joined #pypy
pmp-p has quit [Quit: No Ping reply in 180 seconds.]
pmp-p has joined #pypy
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6094 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7311 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5306 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5637 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1439 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/736 [mattip: build release, release-pypy3.7-v7.x]
<mattip> I recently presented PyPy to the company I work at. One of the questions was "other than speed, why use PyPy"
<mattip> I was stumped for a good answer, especially because we are not always faster
<simpson> You could always ask them why they choose Python, and then ask why they would choose a Python interpreter *not* written in Python. It's Socratic and rude, but gets the point across.
pmp-p has quit [Remote host closed the connection]
pmp-p has joined #pypy
lritter has joined #pypy
<mattip> they choose python because that is what gets the job done, not because they are enamored with the language.
<mattip> from that perspective CPython gets the job done better than PyPy
<mattip> on the topic of rsre: at some point rpython/rlib/rsre/rpy/sre_compile.py and rpython/rlib/rsre/rpy/sre_parse.py diverged slightly
<simpson> Ah. Then don't worry about it; with that sort of logic, any poor decision could be justified. It sounds like they're not actually interested in the motivation, but in excuses.
<mattip> between default and py3.6, it seems somewhere in the update of stdlib to 2.7.16 ???
<mattip> simpson: it is a pragmatic view. If PyPy could get the job done better they would use it.
<mattip> what part of the job, other than speed, does PyPy do better?
<mattip> debugging experience (not really)? better error messages (yes)?
<mattip> packages that work on pypy but don't work on cpython (nope)?
<simpson> I disagree but won't get into it.
<mattip> sorry, I was actually looking for answers, didn't mean to shut down the discussion
<mattip> I started off the talk with a summary of the 15-year retrospective look on morepypy, where cfbolz described the original motivation as
<mattip> people who like python and wanted to write python in python
<mattip> and how it is a very successful research platform for VMs
<mattip> but then as I tried to describe its viability as an alternative interpreter to CPython, the question of "what makes it better" was asked
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6094 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6095 [matti: resync test, py3.6-resync]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1439 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1440 [matti: resync test, py3.6-resync]
<simpson> The answer that I've arrived at, when I hear those sorts of objections, is that the objecter has confused themselves into thinking that they picked a popular or easy tool because it is a good tool. This is really common in business, where folks are often trained to imagine that "good for business" == "good".
<simpson> That's all. I don't think that there's actually any technical meat to bite into. Like, make a person write a CPython extension in C and also the same extension as a plain pure Python module; which is faster? Which is smaller? Which took less effort to write?
<LarstiQ> I'm convinced it's better not to write CPython extensions, but from the perspective of using them/tools already there, PyPy can be more painful.
<LarstiQ> Perhaps an argument is that PyPy is a force acting on the Python ecosystem making it better off, and that is worth supporting?
<mattip> yeah, that was the direction I took: cffi, hpy, stm, various optimizations all started with ideas that pypy helped germinate or even implemented first
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5306 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5307 [matti: resync test, py3.6-resync]
<mattip> which it seems is what simpson was saying too
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
todda7 has quit [Quit: Konversation terminated!]
todda7 has joined #pypy
jcea has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7311 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7312 [matti: resync test, py3.6-resync]
<simpson> I was saying something different, but I like your approach better.
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-32/builds/6095 [matti: resync test, py3.6-resync]
<antocuni> mattip: I think that apart speed, there are very few reasons to choose PyPy over CPython, honestly
<antocuni> the only reason I can think of is to use PyPy TOGETHER with CPython. E.g., you have a package and you test it with both interpreters, as a way to make sure that you don't unnecessarily rely on implementation-specific semantics
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-s390x/builds/1440 [matti: resync test, py3.6-resync]
epsilonKNOT has quit [Quit: ZNC - https://znc.in]
epsilonKNOT has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/736 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/737 [matti: resync test, py3.6-resync]
<bbot2> Exception: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5637 [mattip: build release, release-pypy3.7-v7.x]
<bbot2> Started: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5638 [matti: resync test, py3.6-resync]
todda7 has quit [Remote host closed the connection]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-x86-64/builds/7312 [matti: resync test, py3.6-resync]
todda7 has joined #pypy
<tos9> no one said "memory" yet
<tos9> or "if you have some random optimization that fits a decent number of programs, it's gonna be easier to get it into the interpreter"
<mattip> tos9: my impression is that the light-weight objects and better GC are outweighed by all the memory needed for the JIT traces
<tos9> mattip: yeah I'm not saying always but "sometimes" -- you can obviously tune up or down the latter right
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-win-x86-32/builds/5638 [matti: resync test, py3.6-resync]
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-macosx-x86-64/builds/5307 [matti: resync test, py3.6-resync]
jcea has quit [Quit: jcea]
jcea has joined #pypy
rfgpfeiffer has joined #pypy
todda7 has quit [Remote host closed the connection]
todda7 has joined #pypy
suhdonghwi[m] has quit [Quit: Idle for 30+ days]
pmp-p has quit [Ping timeout: 244 seconds]
pmp-p has joined #pypy
<bbot2> Failure: http://buildbot.pypy.org/builders/pypy-c-jit-linux-aarch64/builds/737 [matti: resync test, py3.6-resync]
rfgpfeiffer has quit [Ping timeout: 265 seconds]
jcea has quit [Ping timeout: 244 seconds]
oberstet has quit [Remote host closed the connection]
rjarry has quit [Quit: ZNC - https://znc.in]
rjarry has joined #pypy
lritter has quit [Quit: Leaving]