On Tue, Jul 21, 2020 at 1:39 PM Gregory P. Smith <g...@krypto.org> wrote:
> > On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado < > pablog...@gmail.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. >> > > +1 agreed. > > """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. > "The co_linetable attribute will hold the line number information. The format is opaque, unspecified and may be changed without notice." ... "Tools that parse the co_lnotab table should move to using the new co_lines() method as soon as is practical." Given it is impossible for tools doing passive inspection of Python VM instances to execute code, co_linetable's exact format will be depended on just as co_lnotab was. co_lnotab was only quasi-"officially" documented in the Python docs, it's spec lives in https://github.com/python/cpython/blob/master/Objects/lnotab_notes.txt (pointed to by a couple module's docs). The lnotab format "changed" once, in 3.6, an unsigned delta was changed to signed (but I don't believe anything beyond some experiments ever actually used negatives?). How about creating something defined and always present for once given the need has been demonstrated. Even if we don't, it will be used, and we will be unable to change it within a release. -gps > -gps > > >> -- >> >> Pablo >> >> On Fri, 17 Jul 2020, 15:55 Mark Shannon, <m...@hotpy.org> wrote: >> >>> Hi all, >>> >>> 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 -- python-dev@python.org >>> To unsubscribe send an email to python-dev-le...@python.org >>> https://mail.python.org/mailman3/lists/python-dev.python.org/ >>> Message archived at >>> https://mail.python.org/archives/list/python-dev@python.org/message/BMX32UARJFY3PZZYKRANS6RCMR2XBVVM/ >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> _______________________________________________ >> Python-Dev mailing list -- python-dev@python.org >> To unsubscribe send an email to python-dev-le...@python.org >> https://mail.python.org/mailman3/lists/python-dev.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-dev@python.org/message/57OXMUBV5FAEFXULRBCRAHEF7Q5GP6QT/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/HFQKDM4TVJPNHHHIJN3BGU2N3CRRXNQY/ Code of Conduct: http://python.org/psf/codeofconduct/
