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
<simpson>
What's the best way to tell RPython that I want to drop all of the elements of a list or map? I know that I can just allocate a new [] or {}, and I'm okay with doing that, but I'm trying to fix *exactly* that antipattern in user-level code, and I don't want to just make the same mistake one level lower.
<cfbolz>
simpson: .clear probably works
<simpson>
cfbolz: For dicts, yeah, good point. For lists, do I do the `l[:] = []` trick?
<cfbolz>
simpson: lists have a .clear method too
<simpson>
Huh, cool. Must have been backported. TIL, thanks.
<cfbolz>
I am not fully sure that rpython supports it
<cfbolz>
del l[:
<cfbolz>
] is another way,
<simpson>
Aha, got it.
<tos9>
Hm. So I haven't spent much additional time trying to see if I know enough to help with ARM macos pypy but I just tried x86_64 pypy via rosetta and I see...
<tos9>
eesh OK there's a decent amount of lines that changed in those CPython PRs, don't think I have time to look at them either yet
jcea has joined #pypy
<arigato>
mattip: unless there is a compelling reason, keep "_thread" disabled even in 3.7
<arigato>
db91b0c1a492 is when it was added to essential_modules
<arigato>
because apparently it's needed by importlib now
<arigato>
I don't mind if sandbox is not working any more (again) and if we're paid another bounty to make it work (again)
<arigato>
or just tell people to use py3.6 for sandbox
<arigato>
but yes, the right thing to do would be to patch importlib to make thread optional
<arigato>
but well, someone needs to check at least that importlib or similar doesn't try to do crazy things with the os module, which it might well do, making sandboxing crash anyway
<arigato>
"_thread.allocate_lock()" for example is likely to make the sandbox crash because of unsupported operation
<arigato>
so the whole point is a bit moot
<arigato>
so it really depends on what importlib does with threads. maybe we can support some minimal emulation of stuff and crash when actually trying to make a new thread
<arigato>
note that reading _bootstrap.py, I'm pretty sure that the global variable "_thread" can be None
<arigato>
but _bootstrap_external.py will crash if it doesn't find a real "_thread" module, even though it could instead use None
<arigato>
so maybe the fix is just to catch ImportError in _bootstrap_external.py and set _thread to None
<arigato>
I don't even want to know why CPython used to have a "dummythread" module but they're not using it
<arigato>
but I guess we could add an alterative dummy _thread module to sandbox or other implementations without _thread, so that importlib keeps being happy
<arigato>
just needs to be put as a mixed module, because it's needed by importlib
<mattip>
not sure I see how to hack around the failing test, which is about a confilict in options
<mattip>
if sandbox requires thread=False and pypy requires thread=True
<mattip>
so pypy would be "suggests" instead?
<arigato>
I didn't look at the failing test, I tried to look at the problem of sandboxing. if we decide that sandboxing on py3.7 is not interesting enough for now, then sure
<arigato>
I'm sure we can tweak the test somehow
<arigato>
or enable _thread in sandbox on py3.7, which I'm sure won't work in practice, but if it makes that test pass then that's all we need for now
<arigato>
don't worry too much about safety in the sandbox, it should crash cleanly when there's anything wrong, and as we didn't try it on py3.7 then I'm sure there is a detail wrong for now
<mattip>
ok, thanks
<mattip>
I put a little "it's on you to work it out" in the sandbox.rst docs and moved thread=False from "require" to "suggests" in e31c7ab93566
<mattip>
the last few failing own tests have to do with updating cffi, and
<mattip>
the change to create an exception chain on the generator/coroutine in cpython PR 1773
<cfbolz>
pff, what an annoying pypy bug: this file should report an illegal break in a finally. instead, it doesn't, because the bytecode compiler doesn't even look at the loop body due to the while 0 https://www.irccloud.com/pastebin/iz1gkkRw/
<mattip>
cfbolz: is cpython any different?
<cfbolz>
yep
<cfbolz>
they do it correctly
<cfbolz>
I should file an issue. not too hard to fix, I suppose
<mattip>
if I put that code in a file and call it, cpython 2.7 and cpython 3.8 do not complain
<mattip>
weird. something is off. Just those 5 lines in a file?
<mattip>
If I flip the "while 0" to "while 1" then I get a SyntaxError
<arigato>
I remember cpython had this kind of issues, which indeed they regard as bugs and attempt to fix (I think it was "if 0: yield" at module level)
<arigato>
(which didn't raise SyntaxError but still made the module code a "generator", which means importing the module did nothing)
<arigato>
compare the exact 3.8.x versions, it might have been fixed in a bugfix release