Hello Mark,

Thanks for writing this email. I do appreciate your effort and your passion for trying to improve Python and this work, but I

have to say that I am a bit frustrated with how are you dealing with this and that unfortunately, I have to admit that this is

absorbing too much emotional energy. On the other hand, I would love it if you could create some Pull Requests after the initial

implementation is done and help us improving the base implementation with a better format and efficient implementations.

> PEP 657 describes how locations for exceptions are to be handled, but is
vague on the treatment of locations for tracing, profiling and debugging.

That is because the pep is called "Include Fine-Grained Error Locations in Tracebacks", we are interested in

fixing that particular problem and by request of many tool authors we have exposed the information as it turns out is

quite useful for them, but we don't want to specify how the information will be used or the semantics for tracing profiling

and debugging. The semantic of that information is already there (the same one attached to AST offsets) and we are not

interested in changing it or altering it, just (as the PEP mentions), propagate it. We are not interested in creating more exhaustive

contracts for the existing information (AST offsets).

> The impact on tools like coverage.py and debuggers should be made clearer. For example, how would one set a breakpoint on line 4 above?

There is no impact on existing tools because we are not changing previous APIs, every API in the PEP is new so these changes do not affect existing tools. Existing

tools could use the new APIs if they wish taking into account that these numbers have the exact semantics as the ones they have in the AST, which we believe is

almost always what they expect. I understand that you may have a different view or disagree with how we view things and that is fine.

> The behavior of tracing and debuggers needs to be described for those locations.

No, there is no reason we need to do that description. That's not the scope in the PEP, we only propagate AST offsets that can be consumed with the same

semantics as the one currently publicly available on the AST. And this is not the primary focus of the pep, which is, again, mainly focused on

"Include Fine-Grained Error Locations in Tracebacks". I will respect if you disagree with this vision, but that is our vision and that is how we have written the PEP.

> PEP 657 claims it is fully backwards compatible, but it cannot be bothnbackwards compatible and consistent.
There are fundamental differences between using ranges and points as locations.

This PEP is fully backward compatible because is not changing any existing API, is only adding new APIs. People that want "points" can use

the same existing APIs that have been used before without any problems because they are there exactly as they were. Is absolutely fine if you have

a different view on what is backwards compatible, but regarding our backwards compatibility policy and PEP 387, this is backwards compatible.

The PEP 657 suggests the impact on startup would be negligible. That is
not quite true.

We already answered this in the other thread you created with exhaustive benchmarks. I don't think we have anything useful to add here.

Regarding your suggestions:

2. Change the C API to a single function:

int PyCode_Addr2Location(PyCodeObject *co, int addr, int *startline, int
*startcolumn, int *endline, int *endcolumn)

This is very reasonable, so I think we can change the PEP and the implementation to do this.

3. Drop the opt-out option.
If the extra information is optional, then the compression scheme must
allow for that; making the code more complex and potentially less
efficient. Does opting out use the start of the range, or the old line,
as the location?

Not possible. The opt-out option is important for a lot of people and, to the point I understand a

very likely requirement for the PEP to be accepted.

4. Drop the limitation on column offsets.
The data needs to be compressed anyway, so allowing arbitrary column
offsets is effectively free.

The limitation can be dropped in the future without problems. This is covered in the PEP:

>>> As specified previously, the underlying storage of the offsets should be considered an implementation detail, as the public APIs to obtain this values will return either C int types or Python int objects, which allows to implement better compression/encoding in the future if bigger ranges would need to be supported.

For the first implementation, we are not interested in dealing with compression or other heavy optimizations, but if you are interested you are more than

welcome to improve upon and drop it in the future.

6. Store all location information in a single table (this applies more
to the implementation than the PEP)
Using four separate objects to hold the location info adds a lot of
overhead for most functions.

The internal representation of the data is an implementation detail. Our plan is to go with the most straightforward implementation first

using separate tables, but if you see an opportunity for improvement and you have some good ideas to merge them into a single table,

then you are more than welcome to make a Pull Request improving upon the initial version.

Regards from cloudy London,

Pablo Galindo Salgado