Derrick Gilland

It looks like sqlalchemy defaults to `checkfirst=True` in `create_all`: https://docs.sqlalchemy.org/en/14/core/metadata.html?highlight=checkfirst#sqlalchemy.schema.MetaData.create_all.params.checkfirst. But maybe sqlalchemy is doing a separate check before issuing the `CREATE TABLE` statement which is causing the race condition?...

Thanks for reporting! This is definitely something that could be improved. Updating the docs would help but beyond just having an example of `event.listen(db._Session, ...)` or `event.listen(db.engine, ...)`, an api...

I like where you're going with that but with a small tweak to mirror `sqlalchemy.event` API: ```python @db.listens_for('before_commit') def pre_commit(...) db.listen('before_commit', pre_commit) ``` which would match `sqlalchemy.event.listen` and `sqlalchemy.event.listens_for`. As...

Are you suggesting memoization around a function that results in the return from the function being stored by it's content hash *and* storing the input parameters to the function as...

Do you have an example of the closure issue you're talking about? I want to make sure I understand what the issue is.

I'm not opposed to having memoization support added to hashfs. I wouldn't likely have any time myself to work on it, though.

I'm not sure this would be changed, but it can be overridden fairly easily. That method could be made a part of hashfs but I just don't know if it...

I don't have a strong opinion either way. Back when I first created this library, the current defaults were what I needed most of the time.

I have no plans to change the way the files are stored on disk. But if that ever did happen, it would be done in a major version change with...

I took a look at your gist and reproduced similar results locally. Inspecting `pydash.get`, I found that your implementation does not handle the same scenarios that pydash does. Some things...