Python 3.10 compiler adds None to co_consts even when None is not used at all.

$ cat x1.py
def foo():
    "docstring"
    return 42

import dis
dis.dis(foo)
print(foo.__code__.co_consts)

$ python3.9 x1.py
  3           0 LOAD_CONST               1 (42)
              2 RETURN_VALUE
('docstring', 42)

$ python3.10 x1.py
  3           0 LOAD_CONST               1 (42)
              2 RETURN_VALUE
('docstring', 42, None)

I wonder what the 3.10 compiler does different to cause this -- in 3.9 that extra None is not in co_consts.

(Note: Mark is on vacation for 2 weeks.)

I think LOAD_CONST None + RETURN_VALUE is added here. And it removed by optimize_cfg().

I don't know how easy to remove this unnecessary None.
But LOAD_COMMON_CONST idea can remove all None from co_consts.
iritkatriel#27

I found anther example for unused constants.

The readall() function.

Python 3.9.5:
co_consts = ('Read until EOF, using multiple read() call.', None)
Python 3.10rc1:
co_consts = ('Read until EOF, using multiple read() call.', True, None)

@pablo This issue seems an optimization rather than bugfix.
But since Python 3.10 produces more unused constants than 3.9, this is a regression.

#72296 removes not all unused constants, but only trailing unused constants.
I think it is enough to fix the regression.

I want to backport it to 3.10 or 3.10.1 after Mark's review.

I want to backport it to 3.10 or 3.10.1 after Mark's review.

Ok, please, add me as a reviewer to the backport once is ready.

New changeset 55c4a92 by Inada Naoki in branch 'main':
bpo-45056: Remove trailing unused constants from co_consts (GH-28109)
55c4a92

Let's wait for 3.10.1 to backport this because I prefer to keep pyc files stable for the release candidate. Turns out that people are already preparing wheels to 3.10 and although this may be fine, I don't want to risk incompatibilities for the release.

Are you sure? I know we're really close to the release, but I'd much rather
change the PYC format during the RC cycle than once we're doing bugfix
releases. I don't think we've ever changed the magic number between bugfix
releases. (I realize this doesn't change the magic number, but it's
probably also the first time we make a change that affects marshal output
without requiring changes in marshal input.

I honestly want to backport it because I think it should not have any negative impact, but on the other hand I don't feel very confident as the release candidate phase is supposed to be as close as possible as the final release and this is not fixing a critical bug. The devguide says about the RC:

>Generally, these issues must be severe enough (e.g. crashes) that they deserve fixing before the final release. All other issues should be deferred to the next development cycle, since stability is the strongest concern at this point.

I am just trying to be cautious but on the other hand we still have anltbet release candidate for people to try it out before the final release so if you all think is better to have this on the RC and this is not going to be an issue for existing universal wheels and the like, then I suppose we can merge it before Rc2

Since we're not changing the magic number, wheels created for rc1 will still work with the final 3.10 (and vice versa!) -- creating a wheel or PYC file just will produce a different sequence of bytes, but there are other things that do that.

Then again, since we're not changing the magic number, it's not the end of the world to put off the backport to 3.10.1.

So I've convinced myself that it actually doesn't matter, and probably it's best to wait for 3.10.1 (changes to the compiler are always risky).

New changeset d41abe8 by Łukasz Langa in branch '3.10':
[3.10] bpo-45056: Remove trailing unused constants from co_consts (GH-28109) (GH-28125)
d41abe8

It goes to 3.10.1 then. Fixed!