Thanks for correcting me, I'll get those updated ASAP.
A good rule of thumb: if you show actual code, run it before you post it!
I frequently want ad-hoc slots to create a structure of related values without the verbosity of a dict with static keys. What's the pythonic method?
E.g. when I want to carry a foo, a bar, and a baz around, but namedtuple isn't right (e.g. I need mutation). I'd prefer
config = Someclass()
config.foo = 1
config.bar = "quux"
config.baz = 3.3
and then using config.bar, etc.over:
config = { 'foo': 1, 'bar': "quux", 'baz': 3.3 }
and then using config['bar']Shouldn't you qualify the exception class as properly as you can?
If you can't I'd expect to check for certain error classes you can handle and else reraise the Exception.
Yes, I would do that in nearly every case.
However, I don't know the larger context. If this were at the top-level of a web services handler where a "return None" indicates a 400 - Internal Server Error, then logging the database failure and stopping is likely acceptable.
Even then, I wouldn't call it good code. However, the goal of this essay seemed to be to give the minimal example, and a more complete example would have required introducing a fake database module with its own exception type. I believe that would have obscured the intent.
I would have preferred real, working code. In this case, with sqlite3. That's fundamentally a pedagogical choice though.
Instead, qualify it by catching Exception:
It's also poor form to "return True" in the exit method of the context manager. If there is no exception then that's not needed at all, and if there is an exception ... well, that code will swallow AttributeError and NameError and ZeroDivisionError, and leave people confused as to the source of the error.