Avoid using dbm.sqlite3 (#242) #243
Conversation
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. Signed-off-by: Adam Williamson <[email protected]>
|
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 |
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.