On Wed, Jul 22, 2020 at 5:19 AM Mark Shannon <m...@hotpy.org> wrote: > > > On 21/07/2020 9:46 pm, Gregory P. Smith wrote: > > > > > > On Fri, Jul 17, 2020 at 8:41 AM Ned Batchelder <n...@nedbatchelder.com > > <mailto:n...@nedbatchelder.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. >
We should have the data about the range at bytecode compilation time, correct? So why not keep it? sure, most existing tooling would just use the start of the range as the line number as it always has. but some tooling could find the range useful (ex: semantic code indexing for use in display, search, editors, IDEs. Rendering lint errors more accurately instead of just claiming a single line or resorting to parsing hacks to come up with a range, etc.). The downside is that we'd be storing a second number in bytecode making it slightly larger. Though it could be stored efficiently as a prefixed delta so it'd likely average out as less than 2 bytes per line number stored. (i don't have a feeling for our current format to know if that is significant or not - if it is, maybe this idea just gets nixed) The reason the range concept was on my mind is due to something not quite related but involving a changed idea of a line number in our current system that we recently ran into with pytype during a Python upgrade. """in 3.7, if a function body is a plain docstring, the line number of the RETURN_VALUE opcode corresponds to the docstring, whereas in 3.6 it corresponds to the function definition.""" (Thanks, Martin & Rebecca!) ```python def no_op(): """docstring instead of pass.""" ``` so the location of what *was* originally an end of line `# pytype: disable=bad-return-type` comment (to work around an issue not relevant here) turned awkward and version dependent. pytype is bytecode based, thus that is where its line numbers come from. metadata comments in source can only be tied to bytecode via line numbers. making end of line directives occasionally hard to match up. When there is no return statement, this opcode still exists. what line number does it belong to? 3.6's answer made sense to me. 3.7's seems wrong - a docstring isn't responsible for a return opcode. I didn't check what 3.8 and 3.9 do. An alternate answer after this PEP is that it wouldn't have a line number when there is no return statement (pedantically correct, I approve! #win). -gps > > Cheers, > Mark. > > > > > -gps >
_______________________________________________ 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/H3YBK275SUSCR5EHWHYBTJBF655UK7JG/ Code of Conduct: http://python.org/psf/codeofconduct/
