search

bbangert / beaker

WSGI middleware for sessions and caching
https://beaker.readthedocs.org/
Other
517 stars 147 forks source link

Avoid using dbm.sqlite3 (#242) #243

Open AdamWill opened 2 months ago

AdamWill commented 2 months ago

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.

AdamWill commented 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).

AdamWill commented 2 months ago

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.