Marc Tamlyn

I don't understand this I'm afraid. It sounds like perhaps you're aiming to change the "standard" introspection process which would make adapters?

Right, got it. This should hopefully be handled by the more flexible "construction" process. Actually monkeypatching changes would ideally still be the devloper's problem, otherwise you run the risk of...

I have used both, at the time Travis was the standard for open source projects, but I don't really mind either way.

Agreed. In my opinion we should try to be explicit about context as well, rather than encouraging passing `request` - this makes testing more complex.

The problem is, if a "plain" validator depends on a cleaning one, then you need to mirror them all.

Custom error handling isn't so necessary there now we have `add_error`. This does lead to the idea that a `ValidationError` could just be bound to two fields and displayed however...

They are part of the "rendering" step, but that doesn't mean that they only belong in the renderer. Thinking about the structural object underneath, it looking something like: ``` {...

I think we can write down the docs for the top part of the API if not the underlying pieces yet. Roughly I was thinking: ``` python { 'adapt': [],...

It's an interesting question where the limits of what the core object is responsible for is. My ideas are currently more around the Serializer class knowing the "rules" about itself,...

The issue with that is that the "rich"er data types supported depends on the transport encoding. In particular, www-form-encoded ONLY supports strings and arrays, no booleans, nested dicts etc.