Open AdamWill opened 2 months ago
This at least makes the test failures go away. It makes Beaker behave the same on Python 3.13 as it did before.
But...I'm not sure it's the right thing to do. It's possible that there are underlying issues with thread safety in beaker which actually mean it doesn't work right with the other dbm backends either, but those backends aren't smart enough to notice, and the beaker tests aren't sophisticated enough to catch it. In which case the correct fix would be to fix that, and accept the new dbm backend. But I'm really not sure whether that's the case, or this is an issue specific to the sqlite3 backend (in which case this makes more sense).
Oh, note on the change from dumbdbm
to dbm.dumb
- there is no dumbdbm
in current Python 3. dbm.dumb
has been its correct name for the whole Python 3 series. Maybe early Python 3's accepted dumbdbm
as a compat thing, I don't know, but dbm.dumb
is the right name. It was redundant in any case since just doing import dbm
would have tried dbm.gnu
, then dbm.ndbm
, then fallen back on dbm.dumb
...but with the new logic of course it's not redundant any more.
Python 3.13 added a new dbm backend, dbm.sqlite3, as the most- preferred choice when you do
import dbm
. This backend causes our test suite to fail with sqlite3 threading violations. This tweaks our dbm loading to just skip sqlite3 and try the other possible backends in the same order as Python < 3.13 did.