Skip to content
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

Python 3.8 wishlist #495

Open
njsmith opened this issue Apr 14, 2018 · 2 comments
Open

Python 3.8 wishlist #495

njsmith opened this issue Apr 14, 2018 · 2 comments

Comments

@njsmith
Copy link
Member

njsmith commented Apr 14, 2018

3.7 is in beta now, so I'm closing the old 3.7 wishlist (#103) and starting a new one :-). This isn't complete or fully-fleshed out, but to get us started, here's some stuff off the top of my head:

@oremanj
Copy link
Member

oremanj commented Apr 18, 2018

Regarding bpo-12857 for KI atomicity, could we just use a flag in the code object co_flags? The decorator could reconstruct the code object with the new flags, like @types.coroutine does. And frames already point to the running code object.

I guess if we're to stop munging frame objects at runtime to make PyPy happy, it would need to be two flags, one meaning "enable KI protection" and one "disable KI protection". The same CO_* flags namespace is used for __future__ flags that only affect parsing, not runtime; setting these on a code object should be safe, and they're very unlikely to be reused for more flags that do affect runtime behavior in the (ha) future. We could pick, say, CO_FUTURE_UNICODE_LITERALS and CO_FUTURE_DIVISION. Or, in a nod to PEP 401, CO_FUTURE_BARRY_AS_FLUFL.

PyPy seems to define the same CO_FUTURE_* flags as CPython does, with the same values.

@njsmith
Copy link
Member Author

njsmith commented Apr 18, 2018

Future flags can be consulted at runtime in case you need to call eval, for example Patsy does this. Reusing future flags that don't mean anything anymore is clever though... However, I'm nervous that reconstructing code objects on the fly will actually make pypy even crankier? It's fine (for some value of fine :-)) for functions statically decorated with @ki_*_protection, but we also apply it dynamically, e.g. when starting a child task or in run_sync_in_worker_thread. Anyway, we should probably move this to its own issue :-). Also, there isn't much point worrying about tiny race conditions here unless we're going to fix all of them, which definitely does require upstream fixes (bpo-29988), so not sure how energy it's worth putting into sneaky solutions like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants