On 21/07/2020 9:46 pm, Gregory P. Smith wrote:
On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder <firstname.lastname@example.org mailto:email@example.com> 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 > thought it did :) > > Should be uncontroversial, but all comments are welcome. > > Cheers, > Mark.
"""When a frame object is created, the f_lineno will be set to the line at which the function or class is defined. For modules it will be set to zero."""
Within this PEP it'd be good for us to be very pedantic. f_lineno is a single number. So which number is it given many class and function definition statements can span multiple lines.
Is it the line containing the class or def keyword? Or is it the line containing the trailing :?
The line of the `def`/`class`. It wouldn't change for the current behavior. I'll add that to the PEP.
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 natural numbers, not ranges of numbers. A lot of tooling would need to be changed.
I think that question applies to later sections as well. Anywhere we refer to a "line", it could actually mean a span of lines. (especially when you consider \ continuation in situations you might not otherwise think could span lines)
Let's take an example: ``` x = ( a, b, ) ```
You would want the BUILD_TUPLE instruction to have a of span lines 1 to 4 (inclusive), rather just line 1? If you wanted to break on the BUILD_TUPLE where you tell pdb to break?
I don't see that it would add much value, but it would add a lot of complexity.