[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Tue, Jul 28, 2020 at 2:12 PM Jim J. Jewett wrote: > ah... we may have been talking past each other. > > Steve Dower wrote: > > On 25Jul2020 2014, Jim J. Jewett wrote: > > > But it sounds as though you are saying the benefit > > [of storing the line numbers in an external table, I thought, > bu

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

ah... we may have been talking past each other. Steve Dower wrote: > On 25Jul2020 2014, Jim J. Jewett wrote: > > But it sounds as though you are saying the benefit [of storing the line numbers in an external table, I thought, but perhaps Pablo Galindo Salgado and yourself were talking only of t

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 25Jul2020 2014, Jim J. Jewett wrote: But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mechanical change from: code.magic_attrname to:

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Sat, Jul 25, 2020 at 12:17 PM Jim J. Jewett wrote: > I certainly understand saying "this change isn't important enough to > justify a change." > > But it sounds as though you are saying the benefit is irrelevant; Jim, if you include what you’re replying to in your own message (like I’m doing

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

I certainly understand saying "this change isn't important enough to justify a change." But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mec

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

> In theory, this table could be stored somewhere other than the code object, so that it doesn't actually get paged in or occupy cache unless tracing is on. As some of us mentioned before, that will hurt the ecosystem of profilers and debugger tools considerably On Thu, 23 Jul 2020 at 18:08, Jim

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

I think this example should be in the PEP. ___ 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.pyt

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

In theory, this table could be stored somewhere other than the code object, so that it doesn't actually get paged in or occupy cache unless tracing is on. Whether that saves enough to be worth the extra indirections when tracing is on, I have no intention of volunteering to measure. I will not

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22Jul2020 1319, Mark Shannon wrote: On 21/07/2020 9:46 pm, Gregory P. Smith wrote: Q: Why can't we have the information about the entire span of lines rather than consider a definition to be a "line"? Pretty much every profiler, coverage tool, and debugger ever expects lines to be natura

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

But on which line is the RETURN opcode if there is more than a docstring? Doesn’t it make sense to have it attached to the last line of the body? (Too bad about pytype, that kind of change happens — we had this kind of thing for mypy too, when line numbers in the AST were fixed.) On Wed, Jul 22, 2

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 5:19 AM Mark Shannon wrote: > > > On 21/07/2020 9:46 pm, Gregory P. Smith wrote: > > > > > > On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder > > wrote: > > > > https://www.python.org/dev/peps/pep-0626/ :) > > > > --Ned. > > > > On

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 10:53 PM Antoine Pitrou wrote: > > > Le 22/07/2020 à 15:48, Inada Naoki a écrit : > > On Wed, Jul 22, 2020 at 8:51 PM Antoine Pitrou wrote: > >> > >>> > >>> I don't think all attempts are failed. Note that current CPython includes > >>> some optimization already. > >> > >

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

Le 22/07/2020 à 15:48, Inada Naoki a écrit : > On Wed, Jul 22, 2020 at 8:51 PM Antoine Pitrou wrote: >> >>> >>> I don't think all attempts are failed. Note that current CPython includes >>> some optimization already. >> >> The set of compile-time optimizations has almost not changed since at >>

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 8:51 PM Antoine Pitrou wrote: > > > > > I don't think all attempts are failed. Note that current CPython includes > > some optimization already. > > The set of compile-time optimizations has almost not changed since at > least 15 years ago. > Constant folding is rewritten

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22/07/2020 12:23 pm, Ned Batchelder wrote: On 7/17/20 10:48 AM, Mark Shannon 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. Thanks for thi

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 21/07/2020 9:46 pm, Gregory P. Smith wrote: On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder > wrote: https://www.python.org/dev/peps/pep-0626/ :) --Ned. On 7/17/20 10:48 AM, Mark Shannon wrote: > Hi all, > > I'd like to announce

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, 22 Jul 2020 19:42:30 +0900 Inada Naoki wrote: > On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou wrote: > > > > > > > > But if we merge two equal code blocks, we can not produce precise line > > > numbers, can we? > > > Is this inconsistent microoptimization that real optimization harder?

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22/07/2020 11:42 am, Inada Naoki wrote: On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou > wrote: > > > > > But if we merge two equal code blocks, we can not produce precise line > > numbers, can we? > > Is this inconsistent microoptimization that real optimiza

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/17/20 10:48 AM, Mark Shannon 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. Thanks for thinking about these aspects of the interpreter, and

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22/07/2020 10:07 am, Antoine Pitrou wrote: On Wed, 22 Jul 2020 12:46:40 +0900 Inada Naoki wrote: On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote: On 18/07/2020 9:20 am, Inada Naoki wrote: It seems great improvement, but I am worrying about performance. Adding more attributes to th

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/22/20 6:42 AM, Inada Naoki wrote: On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou > wrote: > > > > > But if we merge two equal code blocks, we can not produce precise line > > numbers, can we? > > Is this inconsistent microoptimization that real optimization harder

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 7/21/20 5:04 PM, Gregory P. Smith wrote: 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 li

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 6:12 PM Antoine Pitrou wrote: > > > > > But if we merge two equal code blocks, we can not produce precise line > > numbers, can we? > > Is this inconsistent microoptimization that real optimization harder? > > This optimization must be prohibited in future Python? > > All a

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, 22 Jul 2020 12:46:40 +0900 Inada Naoki wrote: > On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote: > > > > On 18/07/2020 9:20 am, Inada Naoki wrote: > > > It seems great improvement, but I am worrying about performance. > > > > > > Adding more attributes to the code object will increas

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Wed, Jul 22, 2020 at 3:43 AM Mark Shannon wrote: > > On 18/07/2020 9:20 am, Inada Naoki wrote: > > It seems great improvement, but I am worrying about performance. > > > > Adding more attributes to the code object will increase memory usage > > and importing time. Is there some estimation of th

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Tue, Jul 21, 2020 at 1:39 PM Gregory P. Smith 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 th

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder wrote: > https://www.python.org/dev/peps/pep-0626/ :) > > --Ned. > > On 7/17/20 10:48 AM, Mark Shannon wrote: > > Hi all, > > > > I'd like to announce a new PEP. > > > > It is mainly codifying that Python should do what you probably already > > thoug

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Fri, Jul 17, 2020 at 10:41 AM Pablo Galindo Salgado 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 memor

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On Tue, Jul 21, 2020 at 11:46 AM Mark Shannon wrote: > On 18/07/2020 9:20 am, Inada Naoki wrote: > > And I am worrying precise tracing blocks future advanced bytecode > optimization. > > Can we omit precise tracing and line number information when > > optimization (`-O`) is enabled? > > I don't t

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 18/07/2020 9:20 am, Inada Naoki wrote: It seems great improvement, but I am worrying about performance. Adding more attributes to the code object will increase memory usage and importing time. Is there some estimation of the overhead? Zero overhead (approximately). We are just replacing o

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

It seems great improvement, but I am worrying about performance. Adding more attributes to the code object will increase memory usage and importing time. Is there some estimation of the overhead? And I am worrying precise tracing blocks future advanced bytecode optimization. Can we omit precise t

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

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 o

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

PEP 626: Rather than attempt to fix the co_lnotab attribute, a new method co_lines() will be added, which returns an iterator over bytecode offsets and source code lines. Why not attempt to fix co_lnotab? -- ~Ethan~ ___ Python-Dev mailing list --

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

PEP 626 wrote: Abstract Python should guarantee that when tracing is turned on, "line" tracing events are generated for all lines of code executed and only for lines of code that are executed. The sample code shows `return` events being executed, even when there is no `return` line -- doesn'

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

https://www.python.org/dev/peps/pep-0626/ :) --Ned. On 7/17/20 10:48 AM, Mark Shannon 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, Ma