Coverage on python 3.12

[vilmar-hillow]

I have a python project that uses pytest==8.3.4 and coverage==7.6.9. I want to migrate from python 3.11 to 3.12.

Just running pytest tests/ works normally on both 3.11 and 3.12. However, executing coverage run --source=my_project -m pytest tests/ works on 3.11, but hangs on 3.12 (displays "collecting 25 items" and moves no forward).

What are the possible causes or debugging steps to take in this scenario?

[nedbat]

I don't know what might be causing this. Coverage works great on 3.12. Can you provide us with a way to reproduce the problem? You could try looking for unusual statements at the top level of your modules. Anything tricky going on?

[vilmar-hillow]

I'll see if I can reproduce it somehow with simplifed abstracted code, though right now it's hard to think on which direction to simplify, given that the code and tests without coverage function without issues on both versions. Are there any debug run options that can help dig in the right direction?

[nedbat]

You don't need to simplify or abstract the code if you can provide a link to your repo with instructions for running the tests. Something is going wrong inside pytest, and coverage doesn't provide debugging options that would show you where.

[vilmar-hillow]

It's work code that can't be readily shared, hence the need for abstraction/simplification. I'll share the code if I manage to reproduce something with similar dependencies, project structure and tests

[vilmar-hillow]

@nedbat I've played around and narrowed down the issue to an import of a large mapping file, here is a reproducible example.

[nedbat]

Thanks, that is a great demonstration. It is a CPython issue, I've reported it here: python/cpython#127953

[nedbat]

The suggestion from python/cpython#127953 is to exclude the mapping.py file from measurement. Will that work for you?

[vilmar-hillow]

Do you mean using omit to exclude the files or something else? I've tried omitting the large mapping before when debugging and it didn't work.

In any case, this should be a trivial refactor for me to use serialized formats (e.g. JSON) instead of a direct import to work around this, though I wonder if there is a way to warn coverage users of this behaviour - I don't think that's too uncommon a scenario that someone will stumble across it in the future.

[gaogaotiantian]

If you have a really large mapping (it seems like your example has like at least 10k lines?), it's probably wise to load it as something like JSON. A really large dict in a .py file will generate a lot of bytecodes and constants, and it would be slower because for each key-value pair, it needs to run some bytecode (instead of loading everything in C-extensions).