Steven Loria

I'm open to this if it doesn't add too much complexity to the codebase. Rather than adding a parameter to provide an executor, I think I'd prefer exposing functions (parse_json,...

@lnunno Your code example looks correct. I would certainly merge a PR adding this to the docs. =)

@TMiguelT Thanks for reporting all these issues and your workarounds. Unfortunately, I don't have much time to look into these, as I'm not using this project at work, and I'm...

Sorry haven't had a chance to look yet... it'd be great if this could be put in line with the other marshmallow-code repos, i.e. use the same templates. The idea...

Rather than modify the AP templates, I think the better approach is to bring this project in line with the rest of marshmallow-code, i.e. use `setup.py` instead of `requirements.txt`. Example:...

Yeah, I think it might make sense to have a `class Meta` option to override type mappings. Perhaps we could call it `type_mapping_overrides`. I would certainly review and merge a...

I think adding adding a `type_mapping_overrides` `class Meta` option that gets merged with `ModelConverter.SQLA_TYPE_MAPPING` is a good first step that gets us 90% of the way. For the `EnumField` use...

I'm considering making the converter class a class member of the schema rather than `class Meta` option, i.e. ```python class SQLAlchemySchema(...): Converter = ModelConverter ``` This could simplify overriding converter...

The converter isn't something that will typically differ per subclass. I'd expect that it would be customized once at the base Schema level. In that sense, it's conceptually closer to...

> Is the only thing this saves in practice not having to use a custom schema opts subclass? Not exactly. You can still get away without a custom options class,...