Hi there! A big joint release today. Mostly security fixes but we also have the final release candidate of 3.13 so let’s start with that! Python 3.13.0RC2 Final opportunity to test and find any show-stopper bugs before we bless and release 3.13.0 final on October 1st. Get it here: Call to action We strongly encourage maintainers of third-party Python projects to prepare their projects for 3.13 compatibilities during this phase, and where necessary publish Python 3.13 wheels on PyPI to be re...
Woo! I’m excited to mess w/ 3.13.
I’ve been pushing to update our Python version, and we went from 3.7 a couple years ago to now being on 3.11 everywhere, and we should get to 3.12 by EOY (and maybe 3.13 if 3.12 goes well). We ran into some weird issues with
pytesteating up all the RAM in 3.12, but that was nearly a year ago now (hence why we went to 3.11 first), so hopefully we won’t have as many roadblocks this time.Huh, I’m going to have to play with this. We have a lot of shared logic between the FE and BE (mostly to support offline mode for our app), and we’ve had bugs when someone forgot to change both. So I’m interested in trying this out for shared business logic and small computations.
On this, anyone know of any projects that can turn a pip-installable package into a WASM module? Ideally, it would fit in our existing FE build pipeline so I could just import it as an ES6 module and the pipeline would generate the file as needed. I’ll certainly look into it when the time comes, just wondering if anyone has already used it.
I’m most excited about the new REPL. I’m going to push for 3.13 upgrade as soon as we can (hipefully early next year). I’ve messed around with rc1 and the REPL is great.
Do you know why pytest was taking up so much RAM? We are also on 3.11 and I’m probably going to wait until 3.13 is useable for us.
We looked into it a bit, and it seems it’s not freeing test case instance data (this bug, and some related bugs). We use
unittest-style tests, but use pytest as a runner, and our test suite is all kinds of bloated. Basically, a typical test looks like this:def BaseTest(unittest.TestCase): def setUp(self): for fixture in self.FIXTURES: db.add(fixture) def tearDown(self): db.clear() # I'm pretty sure this actually clears memory, so not our issue def MyTest(BaseTest): FIXTURES = [ ... large list of data ... ] def test_example(self): result = Service.do_operation() # uses FIXTURES ... asserts ...My best guess is that
FIXTURES(and anything on the TestCase) is being kept in memory, and we do this everywhere.Our plan is to separate our service layer from our db layer, which will dramatically reduce memory in these test case instances (we’re doing it anyway for other reasons). At the same time, we are considering porting to pytest-style tests, which will give us an opportunity to rearchitect how we handle fixtures. Some of our repos have already switched, but our larger repos haven’t.
That said, this is pretty old information. We ran into these issues around the end of last year, and haven’t looked at it since, but will in the next couple of months (we do Python upgrades around year end). It’s possible it is already fixed, either in Python or pytest (bug is still open, but no activity for a year).
Anyway, if you run into weird memory issues when running tests w/ Python >=3.12, this might be the culprit.
Thanks for sharing. We use all pytest-style tests using pytest fixtures. I’ll keep my eyes open for memory issues when we test upgrading to python 3.12+.
Very helpful info!