PEP 657: use 0-indexed offsets (GH-2022)

This commit is contained in:
Batuhan Taskaya 2021-07-04 21:02:22 +03:00 committed by GitHub
parent 3b34e282fd
commit 5fc4119624
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 12 additions and 8 deletions

View File

@ -210,14 +210,18 @@ Offset semantics
^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^
These offsets are propagated by the compiler from the ones stored currently in These offsets are propagated by the compiler from the ones stored currently in
all AST nodes. They are 1-indexed and a value of 0 will mean that the all AST nodes. The output of the public APIs (``co_positions`` and ``PyCode_Addr2Location``)
information is not available. Although the AST nodes use ``int`` types to store that deal with these attributes use 0-indexed offsets (just like the AST nodes), but the underlying
these values, ``uint8_t`` types will be used for storage in the new map to implementation is free to represent the actual data in whatever form they choose to be most efficient.
minimize storage impact. This decision allows offsets to go from 0 to 255, The error code regarding information not available is ``None`` for the ``co_positions()`` API,
while offsets bigger than these values will be treated as missing (value of 0). and ``-1`` for the ``PyCode_Addr2Location`` API. The availability of the information highly depends
We believe this is an acceptable compromise as line lengths in Python tend to on whether the offsets fall under the range, as well as the runtime flags for the interpreter
be much lower than this limit (a query of the top 100 packages in PyPI shows configuration.
that less than 0.01% of lines were longer than 255 characters).
The AST nodes use ``int`` types to store these values. The current implementation, however,
utilizes ``uint8_t`` types as an implementation detail to minimize storage impact. This decision
allows offsets to go from 0 to 255, while offsets bigger than these values will be treated as
missing (returning ``-1`` on the ``PyCode_Addr2Location`` and ``None`` API in the ``co_positions()`` API).
As specified previously, the underlying storage of the offsets should be As specified previously, the underlying storage of the offsets should be
considered an implementation detail, as the public APIs to obtain this values considered an implementation detail, as the public APIs to obtain this values