Remove deprecated code.co_lnotab

[picnixz]

Feature or enhancement

Proposal:

This is an issue to track the removal of code.co_lnotab deprecated since 3.12 and scheduled for removal in 3.14.

In #101865, it is marked "may be removed" but I think it should be removed. If not, we should harmonize the docs which sometimes state "will be removed" and sometimes say "may be removed" (also the corresponding tests are marked as "todo: remove in 3.14").

Has this already been discussed elsewhere?

No, so we can discuss here whether we should remove it now or not.

Links to previous discussion of this feature:

#101865

Linked PRs

• gh-119664: Remove deprecated co_lnotab #119665
• gh-119664: use conditional removal notice for codeobject.co_lnotab #120263

[iritkatriel]

In #101865, it is marked "may be removed" but I think it should be removed.

What is the reason for removing it?

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

For someone who uses it and will be required to change their code this is not minor. We don't always remove things just because we can, if they are not getting in anyone's way. I think this decision needs to be discussed.

[picnixz]

Oh it was actually scheduled for removal in Python 3.14 (deprecated in 3.12). Actually, it was scheduled for removal for 3.12 but since no DeprecationWarning was set in 3.10, it got delayed (see https://peps.python.org/pep-0626/#backwards-compatibility).

EDIT 1: Also, in 3.10 and 3.12 it was said "will be removed" but for 3.13 it was marked "may be removed". Feel free to close the related PR if a discussion is needed (or maybe I should open one on discourse?).

EDIT 2: If I were to motivate the reason, there are two points to adress:

• This is marked as pending removal for 3.14 in the What's New pages. As such, it gives me the feeling that this is scheduled for removal. While I agree that there are places when it is not sure whether it would be removed, the stable version tells you that it will.

• The second reason is that none of the current code is using that attribute anymore and maintaining it required additional conversion functions. It would simplify a bit the codeobject.c file.

Now, if you think that someone is using it and we would break it, I think they should likely update their code and use the new co_lines() method because it was designed to be more practical. Again, this is my personal opinion on the topic and I am not an expert. Nonetheless, if you decide to keep it, I think we should at least harmonize the docs.

[markshannon]

I don't see any need to remove this just yet.

We will probably need to remove it at some point, in order to change the internal format of the position table, but we might as well leave until then.

[picnixz]

Then would you consider the rewording of the removal notice as presented in #120263? (so that we don't have confusion in the future)

[picnixz]

(Closing as wontfix since I actually closed the PRs. We'll reopen once we need to actually remove it I think, or just create another issue)