On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado email@example.com wrote:
I like the proposal in general but I am against removing lnotab. The reason is that many tools rely on reading this attribute to figure out the Python call stack information. For instance, many sampler profilers read this memory by using ptrace or process_vm_readv and they cannot execute any code on the process under tracing as that would be a security issue. If we remove a 'static' view of that information, it will impact negatively the current set of remote process analysis tools. The proposed new way of retrieving the line number will rely (if we deprecate and remove lnotab) on executing code, making it much more difficult for the ecosystem of profilers and remote process analysis tools to do their job.
"""Some care must be taken not to break existing tooling. To minimize breakage, the co_lnotab attribute will be retained, but lazily generated on demand.""" - https://www.python.org/dev/peps/pep-0626/#id4
This breaks existing tooling.
On Fri, 17 Jul 2020, 15:55 Mark Shannon, firstname.lastname@example.org wrote:
I'd like to announce a new PEP.
It is mainly codifying that Python should do what you probably already thought it did :)
Should be uncontroversial, but all comments are welcome.
Cheers, Mark. _______________________________________________ Python-Dev mailing list -- email@example.com To unsubscribe send an email to firstname.lastname@example.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://email@example.com/message/BMX32UAR... Code of Conduct: http://python.org/psf/codeofconduct/
Python-Dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://firstname.lastname@example.org/message/57OXMUBV... Code of Conduct: http://python.org/psf/codeofconduct/