build(python): Support Python 3.12

[stinodego]

Closes #11348

Changes

• Update Python version in the CI.

[stinodego]

@MarcoGorelli @alexander-beedie any idea why the bytecode parser used for the inefficient apply warning fails a bunch of tests on Python 3.12?
https://github.com/pola-rs/polars/actions/runs/6686165281/job/18165214724?pr=12094

[alexander-beedie]

@MarcoGorelli @alexander-beedie any idea why the bytecode parser used for the inefficient apply warning fails a bunch of tests on Python 3.12?

Probably some new/reworked opcode specializations in 3.12 as part of the "faster cpython" initiative; I can take a look and account for them 👍

[stinodego]

@alexander-beedie Only bytecode parser failing on Python 3.12 now... all yours!

[alexander-beedie]

@alexander-beedie Only bytecode parser failing on Python 3.12 now... all yours!

Done! #12348 ✌️😎

[stinodego]

@alexander-beedie I am consistently getting an import time regression on ubuntu / Python 3.12 😕 Any idea what could have triggered this? Here's the timings:
https://github.com/pola-rs/polars/actions/runs/6827502341/job/18596392679?pr=12094

[alexander-beedie]

@alexander-beedie I am consistently getting an import time regression on ubuntu / Python 3.12 😕 Any idea what could have triggered this? Here's the timings: https://github.com/pola-rs/polars/actions/runs/6827502341/job/18596392679?pr=12094

Hmm... will try to take a look tomorrow 👌

[alexander-beedie]

Hmm... will try to take a look tomorrow 👌

And by "tomorrow" I apparently mean two days later 😅 But... I think I have an explanation and will be pushing an update shortly! The good news is that imports have not become meaningfully slower; it appears to be an import-test artefact that I can address to get more consistent/reliable results.

[stinodego]

@alexander-beedie The test still fails even with your latest update 😞

[alexander-beedie]

@alexander-beedie The test still fails even with your latest update 😞

Maddening... that test is absolutely rock-solid for me now. I'll instrument it some more, but maybe we'll need to adjust the import timing threshold on a per-architecture basis, hmm. Will look at the test runner logs for clues 🤔

From my home machine (an admittedly fast M2 Max) -

Import times achieved over 10 tries:
Min => 38,665μs, Max => 65,463μs)

(0) 38,665μs
(1) 45,161μs
(2) 61,242μs
(3) 58,141μs
(4) 56,683μs
(5) 63,325μs
(6) 69,749μs
(7) 65,463μs
(8) 62,225μs
(9) 55,672μs

Note that those are debug build timings; I see release build timings as low as 28,171μs 🚀 (< 0.03 secs)

[alexander-beedie]

Instrumented a little and increased the number of allowed tries from three to ten 👀 Results are clear enough; the test now looks pretty stable, but import timings on the 3.12 CI (hardware?) really ARE consistently slow...

Import times achieved over 10 tries:
Min => 244,554μs, Max => 320,321μs)

(0) 268,935μs
(1) 256,196μs
(2) 262,766μs
(3) 264,437μs
(4) 244,554μs
(5) 320,321μs
(6) 269,662μs
(7) 279,400μs
(8) 300,972μs
(9) 261,502μs

Will switch to 3.12 locally and see if there's a drop-off (my own timings were 3.11 on Mac - can also try 3.12 on my NAS/Ubuntu box and see how that looks 💭)

[stinodego]

Will switch to 3.12 locally

It has to be related to Python 3.12, possibly in combination with the CI runners. After all, the Python 3.8 Ubuntu run passes, as well as the Python 3.12 Windows run 🤔

[alexander-beedie]

It has to be related to Python 3.12, possibly in combination with the CI runners. After all, the Python 3.8 Ubuntu run passes, as well as the Python 3.12 Windows run 🤔

Might have a lead; apparently the performance of coverage has cratered in 3.12 in some cases. The two different machines/architectures I've tried on 3.12 both seem fine when running the import test directly, but that doesn't cause coverage to run - whereas running under CI does...

[alexander-beedie]

Yup, looks like that's it; was finally able to replicate the slow import timings under 3.12 on the virtualised Ubuntu install on my NAS; enabling coverage causes them to fall off a cliff (eg: 2-3x slower than expected). The same does not seems to happen on macOS (Apple Silicon) or Windows.

Looks related to these issues: python/cpython#107841 and nedbat/coveragepy#1665.
Disabling the coverage flag -cov for 3.12 Ubuntu CI (until this is resolved) should fix the test failure 🤔