Towards 0.4

[tomchristie]

Lots of big changes here. I'll keep the synopsis to a minimum...

• Rewrite type system. (Don't use type subclasses, just plain old python objects please.)
• Rewrite components. (Much simpler. Components as plain objects allows per-component configuration, rather than everything in a big global settings dict.)
• Add event hooks.
• ASGI becomes the asyncio interface, since it's latest re-write now supports our requirements.
• OpenAPI to become the default schema representation.
• Drop coreapi and coreschema - Schema generation and client library is now part of this package.
• Drop built-in support for ORMs, push towards third-party instead.

Here's the README

TODO:

• Format support, eg. 'datetime' validation.
• Enforce location=query|path|body
• Enforce path fields as required, and matching uritemplate.
• Remove uritemplate dependency.
• Support Type.
• Deal with non-unique names in Routing (asserts at document level)
• Include Type and annotation information on schema.
• Allow Type subclasses to be used in validations.
• ASyncIO Support, with ASGI
• Static Files support for ASGI
• Update uvicorn for ASGI Support - See ASGI support uvicorn#63
• Resolve issue with dependency injection not persisting parameters between functions.
• Clean up TODOs in docs.

Later:

• Add url to Section.
• Guard against uvicorn calling into old-style interface, and yell loudly.
• Response schemas in OpenAPI.
• Consider types/fields instead of types/validators.
• Bool and null coercions for query string and form data.
• Use ConfigurationError, not assert
• Subclassing Type and handling allOf relationships in JSON schema.
• Reintroduce API docs.
• Reintroduce command routing.
• Test coverage & fixups.
• Third-party Flask, Django variants.
• Check for configuration errors when instantiating router from Document.
• Use url not base_url for decode option from HTTPTransport.
• Support errors override on type system.
• Client should validate path/query/body parameters are appropriate primitive types only.

[audiolion]

s/_TemproraryFileWrapper/_TemporaryFileWrapper

[audiolion]

perhaps mention that it is a unique, case-insensitive name?

[tomchristie]

Thanks for the review! The name isn't actually case-insensitive, I'm just using the lowercase for stylistic reasons.

[GomZik]

Not sure, that we can assume, that dict has ordered keys since 3.6

[tomchristie]

dict is ordered in cpython 3.6 as an implementation detail, and guaranteed ordered in 3.7+

We don't strictly need ordering, it's only for stylistic purposes of eg. returning JSON outputs that are always in the same way as the fields in the codebase, so it's not a massive problem if there are a few edge cases of platforms that could get unordered outputs, but I'd be happy if there's any stricter checking that we can do, to also check if we're on cpython or some other implementation.

[sirex]

The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon

https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compactdict

I could not find anything about guaranteed dict order since 3.7+.

[jgirardet]

The boss said it : https://mail.python.org/pipermail/python-dev/2017-December/151283.html

[jgirardet]

In case of 404 requests, the on_request hook is not called but the on_error is called. The on_error has no idea if the on_request things were done or not.
In my case I had failure because on_errors had to close a database transactino which wasn't opened.
I don't know if it's a big problem or not but I think that user should be aware of that special case to deal with it because 404 seems to be the only situation where it happens (I tink because url lookup occurs before injection)

[Bogdanp]

I think this list and the on_error list should be reversed so that request and response hooks are always at the same "depth" in the request stack. I went into more details why here.