-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Push PyPy3 compatibility to 100% #58
Comments
Ok, so PyPy doesn't have Hm, In CPython, the That solution is not applicable to a REPL server - we really need an async raise to trigger the exception in the desired thread (the one that's running the REPL session we want to send the Ctrl+C to). So maybe a small addition to Hm. Another approach: It's not as general as the current CPython solution, since it can only do OS signals, not arbitrary exceptions, but that's good enough for what we want to do here. To make it general (just for feature parity), we could provide a mechanism that usurps e.g. SIGUSR1 to asynchronously send any exception via a global dictionary acting as a mailbox, but the user code still needs to enable OS signals on PyPy (specifically for the targeted block of code in the target thread) for that to work. OTOH, this is Python, where explicit is better than implicit. OTTH, that takes up one OS signal. OTFH, we can provide a decorator that adds the PyPy-specific The only unclear thing is what the PyPy docs mean by that a signal might be handled in either the main thread or one currently inside such a If we go the mailbox route, we should probably keep track of thread idents that have been marked as accepting async raises. Global dict, clean up in a This approach gives us a consistent This way we can also know at the time |
Macros should be fine, MacroPy has been tested on PyPy. |
Quickly tested on PyPy 7.3.0 (
But mostly, it's already working, including all macros! |
Meh. Tested, and it turns out So it may be we really need to implement |
Regarding
Meh, |
Alternative way to signal a particular thread: signalfd. See some context. Just need to test if it works in PyPy... |
PyPy3 looks promising, as it's rumored to be fast, and it supports version 3.6.9 of "the Python standard". Our main target platform just so happens to be Python 3.6.x.
Our PyPy3 compatibility is already near 100%. This issue documents what remains to be done.
async_raise
.ast
close enough to CPython's?unpythonic.misc.async_raise
? This may or may not work, depending on what is available in PyPy3'sctypes
module. (It's only needed for remote Ctrl+C in the REPL server, but that's a nice feature to have.)__del__
methods, since they may be delayed or not called at all, and in most cases having a__del__
is just not pythonic anyway.unpythonic.tco._jump
doesn't (really) matter, since its only purpose is to print a warning.The one inunpythonic.dynassign._DynLiveView
is more serious. How to get around it? Awith
block is no solution here, since the_DynLiveView
instance is returned byunpythonic.dyn.asdict
, so it has indefinite dynamic extent, depending on the code that callsasdict
. Requiring users to call a.close()
method explicitly just invites omission by accident or even on purpose (e.g. who ever callssocket.shutdown()
?). OTOH, maybe_DynLiveView
could be a singleton? The dynamic scopes are already context-managed, and that's really all that matters.How about for the lose, instead. Can't work, since the dynamic scope stacks are thread-local. Having observers linger around a bit longer than they absolutely need to, or not having them cleaned up when the process exits, are not really a problem. In practice, the old solution should be fine in PyPy, too. Hence, reverted in 089f7cc._DynLiveView
singleton FTW. 1a0f0f5.The text was updated successfully, but these errors were encountered: