Add python 3.12 to run_tests github workflow

[bosh]

Expecting to expose issues via github that need addressing for the upgrade -- not really ready to review

[bosh]

Looks like there are issues in some platform-specific code, or their tests: Lisy, PKONE, and Spike

[avanwinkle]

I've seen these issues before, something to do with how MPF tests setup the serial devices and send/expect serial commands. I explored a little bit but didn't get too far, I was looking at PKONE and it seemed like the commands were being sent multiple times and the test only expected the responses once.

Thanks for taking a look, hopefully you have more success than I did!

[bosh]

Haha thanks - I'm glad to see it's not an excessive amount of errors. I'll give it a shot one of these days.

With Python 3.8 now in EOL, what's the MPF practice for deprecating 3.8 support?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bosh]

After all this investigation, I'm starting to think the common thread between all of the errors is linked to behavior of queues and dequeuing operations, especially in test fakes. Windows and *nix systems seem to different in dequeue behavior but I can't put my finger on it.

First, something completely unrelated - 3.12 shows warnings on using ast.Number/etc instead of ast.Constant. There's a piece of supported-feature-check code that enables Constant, so maybe for other library compatibility we need to keep it as is. If not, just replacing all the deprecated ast types with Constant seems to work across all versions, could be worth pulling out to .57 -- https://github.com/missionpinball/mpf/pull/1856/files#diff-272a790e6b3c028190676eceb8a70434bdc1473434f47e4cc4826efdbbe70287 or maybe we don't change it at all!

[bosh]

There are some groups of failures, and I'm going to leave notes about each in hopes of pointing at some common source.

First, the Lisy test. I ran different combinations of command, and only the flash-related section of the test fails (after it are some sound tests, which work fine when run in another order). The specific error is that an expected command is never cleared from the expected set, suggesting it is never sent. Flash is time-based, so I ran slightly longer before checking, and Windows passed (but everything else started failing). Maybe the test time is exactly on the cutoff time and Windows has a different precision or tiebreak than nix, so it only needs a moment longer?

[bosh]

Next, PKONE: These tests all fail the same way in setup, on mac/unix with 3.12 only --
The first command (maybe all of them?) seems to be double sent, but the mock manager clears the command from the set on the first and bombs on the second. More specifically, the first command is PCNE (E is a separator), and the second is received as PCNEPRSE. Somehow the first command is not being cleared out, and I suspect it's related to the internal behaviors of BaseMockPKONE#queue

Finally, Spike: Interesting that the commonality with all three is that they're in platform integrations, and I think it's due to them all having mock serial implementations that they interact with in test. The Spike tests fail because they get a node value of 255 instead something within the range 0-15. Feels to me like a (leading? https://github.com/missionpinball/mpf/actions/runs/12295483583/job/34312458054#step:5:1256 ) FF value from a previous command is being read as the next command's node number. Again the serial mock seems to be reusing an old value, and uses a queue under the hood.

AHA Okay a clue -- they all use MockSerial under the hood. Maybe there's one common piece to all of it. More digging to come. Edit: nope lol, looks like MockSerial is just an interface with a bunch of stubs that will yell at you if you try to use them. So back to the queue usage in Lisy/PKONE/Spike code theory