On 28 January 2018 at 17:35, Pau Freixes <[email protected]> wrote: >> At a technical level, the biggest problems relate to the way we >> manipulate frame objects at runtime, including the fact that we expose >> those frames programmatically for the benefit of debuggers and other >> tools. > > Shoudnt be something that could be tackled with the introduction of a > kind of "-g" flag ? Asking the user to make explicit that is willing > on having all of this extra information that in normal situations > won't be there.
This is exactly what some other Python runtimes do, although some of them are also able to be clever about it and detect at runtime if you're doing something that relies on access to frame objects (e.g. PyPy does that). That's one of the biggest advantages of making folks opt-in to code acceleration measures, whether it's using a different interpreter implementation (like PyPy), or using some form of accelerator in combination with CPython (like Cython or Numba): because those tools are opt-in, they don't necessarily need to execute 100% of the software that runs on CPython, they only need to execute the more speed sensitive software that folks actually try to run on them. And because they're not directly integrated into CPython, they don't need to abide by our design and implementation constraints either. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
