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
<kenaan>
arigo py3.6 3a35a0ae4463 /lib_pypy/_lzma.py: #3090: lzma sometimes fails to decompress a file Fixed by back-porting CPython commit a3c53a1b45b05bcb69660eac5a2714...
jacob22_ has quit [Read error: Connection reset by peer]
<tos9>
I'm not sure I follow the GIL part of that (and I don't see any GIL discussion in https://docs.python.org/3/library/ctypes.html other than it saying the GIL *isn't* released?)
<tos9>
But the other part of that seems somewhat easily solvable? I.e., it seems like the goal should be to provide all the C API that cpyext emulates, and use the same names as cpython?
<mattip>
could you share how you use ctypes.pythonapi?
<tos9>
which seems... weird but also not like something that pypy can't support
<mattip>
I see. It would basically disable jitting for any overridden function and be really slow
<tos9>
yeah
<tos9>
I don't think those expectations are unfair to break for a library of this kind
<mattip>
I’m also not sure we could do it. You are not supposed to assign to tp methods after PyTypeReady, we only support it on user types because of some obscure numpy code,
<tos9>
mattip: yeah so that's why I split the question into two parts (though maybe I haven't thought through the connection)
<tos9>
mattip: ctypes.pythonapi is just fancy calling syntax, no
<mattip>
and I am pretty sure it would not work on user types
<tos9>
so that was the piece I was asking about -- whether after that existed this library still didn't work because of breaking lifecycle expectations is yeah seemingly easy to check after
<tos9>
but like hypothetically some other library could be using `ctypes.pythonapi` just as a convenient way to call CPython API functions no
<tos9>
and be doing so "correctly"?
<mattip>
S/user/built in
<mattip>
I don’t think we could make it work without a lot of messing around
<tos9>
I'm not suggesting pypy should emulate cpython's behavior if it turns out assigning to tp methods works there and not pypy, just asking whether it's reasonable to make `ctypes.pythonapi.PyList_New(12)` work
<tos9>
mattip: for this lib or in general? (and thanks for indulging me :)
<mattip>
It was more than “there are better ways”, but I forget the details of why we decided it was not functional
<tos9>
mattip: /nod -- ok, think at least I found the commits that removed pythonapi, so can dig through to see if there's any rationale in there
<mattip>
I would have to go back to the commits around when we removed it
<mattip>
it might mean sphinx internals are badly designed, and it needs a rewrite, but
<mattip>
think how much CI time is wasted on an inefficient implementation
<cfbolz>
mattip: you're getting more and more compelling
jvesely has quit [Quit: jvesely]
CrazyPython has joined #pypy
jvesely has joined #pypy
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
antocuni has joined #pypy
jvesely has quit [Quit: jvesely]
kipras has joined #pypy
YannickJadoul has joined #pypy
kipras has quit [Read error: Connection reset by peer]
<YannickJadoul>
Hi, all. Suppose I'd like to add a function to a module (such as `breakpoint()` to `__builtin__`), what is the intuition/rule of thumb/... on appleveldefs vs interpleveldefs?
<YannickJadoul>
I think I get the distinction between the two (correct me if I'm wrong, though), that interpreter level is to app level +- as a C implementation to Python implementation in CPython?
<YannickJadoul>
But what's the intuition on deciding where to add a new one?
xcm has quit [Read error: Connection reset by peer]
<mattip>
is a bit terse, but tries to give some direction
<YannickJadoul>
mattip: Oh, sorry, I had missed that part of the docs!
<mattip>
I thought it gave more motivation. In general, app-level is easier to write since it is pure python
<mattip>
so if you can, do it there. Actually, I prefer putting things in lib_pypy if possible
<mattip>
since then no translation is needed
<YannickJadoul>
So there's no real difference in performance or anything? Just that sometimes you do need to access the interpreter itself, so you have no choice?
<cfbolz>
YannickJadoul: and some things are hard or impossible to express in applevel
<cfbolz>
For the case of breakpoint it should be an applevel function in the builtin module, since it's not performance sensitive (the debugger almost always requires human input)
<cfbolz>
lib_pypy is great, but mainly works for full modules at applevel
gracinet has quit [Ping timeout: 276 seconds]
CrazyPython has quit [Ping timeout: 264 seconds]
<YannickJadoul>
cfbolz: Thanks, I think I understand it a bit better now :)
<YannickJadoul>
Indeed, I'd realized that breakpoints aren't performance-sensitive, but I was wondering if there's a general guideline :)
<cfbolz>
YannickJadoul: right
<cfbolz>
First approximation: write applevel if you can get away with it 😉
<YannickJadoul>
cfbolz: Great, thanks again! Let's see if we can get this running :)
jvesely has joined #pypy
<cfbolz>
YannickJadoul: it's probably a bit annoying to unittest?
jvesely has quit [Quit: jvesely]
<mattip>
cfbolz: any idea why "firstarg()" would be None in funcrun_obj?
<mattip>
for set.__init__(0)
<cfbolz>
mattip: is that the bug?
<cfbolz>
mattip: no, sounds very strange
<mattip>
yes, at least in pyinteractive, it gets to pypy/pypy/interpreter/gateway.py", line 857, in funcrun_obj
<mattip>
more to the point, where should a test be added?
<cfbolz>
mattip: can you run pyinteractive with -v?
<tos9>
breakpoint() just calls sys.breakpointhook so I suspect it's not too bad to unittest it
<YannickJadoul>
tos9: They do reset `breakpointhook` with `__breakpointhook__` in `test_breakpoint_with_breakpointhook_reset`
<tos9>
YannickJadoul: right, that part is fine
<tos9>
YannickJadoul: but there is no test that covers the behavior "__breakpointhook__ is the breakpoint hook that was relevant at process startup"
<tos9>
(that I see)
<YannickJadoul>
tos9: Oh, and I quickly checked: __breakpointhook__ is completely available to be set or deleted
<tos9>
YannickJadoul: so if you forget to implement that (and implement it say as a non callable at all), I think you pass all the tests there
<mattip>
just like sys.__stderr__
<YannickJadoul>
Hmmm, maybe, but they do check if the mocked up version of `pdb.set_trace` is called
<tos9>
YannickJadoul: ok, that's.. unfortunate I guess, but probably consistent with __stdout__ and __stderr__, and probably is just "laziness" or the fact that partially mutable modules is probably annoying, but yeah to me those shouldn't be mutable... but whatever, I guess in PyPy they should do what CPython does
<YannickJadoul>
FWIW, I was also surprised reading/seeing that
<mattip>
if you do that, then you can just run the cpython tests in pypy/lib-python/3/test/test_builtin.py
<mattip>
the advantage: no translation needed, it should be very quick to implement and test
xcm has quit [Remote host closed the connection]
<mattip>
well, at least a proof of concept, until someone decides to lock down assigning to __builtins__
xcm has joined #pypy
<arigato>
in my opinion implementing the new builtin in lib_pypy/__init__.py seems very unexpected
<arigato>
just stick it in pypy/module/__builtin__/app_something.py
xcm has quit [Remote host closed the connection]
xcm has joined #pypy
<arigato>
(actually, you can't implement breakpoint() in lib_pypy because doing so makes an extra frame, which is unexpected; but if done in module/*/app_* then the extra frames are hidden)
jcea has quit [Quit: jcea]
firespeaker has quit [Ping timeout: 240 seconds]
CrazyPython has joined #pypy
CrazyPython has quit [Read error: Connection reset by peer]
<cfbolz>
mattip: ok, it's also a pypy2 segfault, with a small variation
<cfbolz>
set.__init__.im_func(0)
<cfbolz>
pretty serious bug, probably has existed since 2006 :-(
firespeaker has joined #pypy
jcea has joined #pypy
<YannickJadoul>
mattip: "if you find a bug in that, please fix the PEP": there's indeed one "return None" missing; what do I do about that (except for writing it correctly for PyPy)
<YannickJadoul>
But I can't import unittest.mock.patch, it seems, so I can't write similar tests as in CPython. No idea if there's a better way? Manually mocking by setting `pdb.set_trace = lambda: None`?
<cfbolz>
yes, mock manually
<cfbolz>
YannickJadoul: ^^
<kenaan>
cfbolz fix-descrmismatch-crash da9a65e1debd /pypy/interpreter/: fix first level of problems: args.firstarg() is always None in this context, use w_obj instead
<YannickJadoul>
cfbolz: Alright
YannickJadoul has quit [Quit: Leaving]
firespeaker has quit [Quit: Leaving.]
xcm has quit [Killed (orwell.freenode.net (Nickname regained by services))]
xcm has joined #pypy
firespeaker has joined #pypy
xcm is now known as Guest89951
Guest89951 has quit [Killed (cherryh.freenode.net (Nickname regained by services))]