Steven Loria

> Loading rich python objects seems like a significant departure from marshmallow's existing functionality. Perhaps this is only relevant for the time-related fields like DateTime. I imagine are cases where...

I may be misunderstanding the OP. I thought they were only dealing with `dict`s, not instantiated objects. > (1) is all we need. We build dicts of data (json, essentially)...

> The only down side I see to baking this into the core fields is that it would add type checking overhead that rarely is needed. Yeah, but this seems...

T-M is using a vendorized [fork](https://github.com/lyft/marshmallow/tree/9319f89fb00d83aa60a6f3cb91a49c4fa8572152) of 2.15.1. v3's removal of all validation on serialization probably made up a significant portion of the difference.

Now that we assume that data to dump is valid, deserialized data, the types should be known upfront, right?

I agree with the direction here. Do we agree that the target end state is to cache accessors for all fields ahead of time? Since we assume `dump` input is...

Related to my above comment: we could even support setting getters in both directions (dump and load). This would allow you to validate objects (not just `dict`s), which is [clunky](https://github.com/marshmallow-code/marshmallow/issues/1393)...

That said, `load`-ing objects is semantically tricky. For example, what would `unknown` validation look like? Maybe it's not something we should support.

Thanks for the PR and the kind words, @xLegoz . Looks potentially useful and the implementation is straightforward. It seems, however, that it would be straightforward to meet your use-case...

Sounds good. I'm not opposed to merging this, but I'd like to take some time to collect my thoughts and get feedback on this. For one, I think it might...