@fazpu thank you for the kind words! 😄

@carltongibson I think as the maintainer of the package in question I should step forward and write a PR for this - getting on that

Also, I'd be curios about the planned 3.8 changes you are talking about - is OpenAPI support planned, or are there incoming changes to Core API to enable handling of this?

And on the same line of thought, I was always curios why it was decided to create a new format instead of using an already existing one (be it OpenAPI or whatever else) - is there anywhere I could read about that?

@axnsan12 Thanks (again) for the input.

And on the same line of thought, I was always curios why it was decided to create a new format instead of using an already existing one (be it OpenAPI or whatever else) - is there anywhere I could read about that?

It's just a history thing really. At the time there were a number of competing description formats; it wasn't clear that Swagger would be the winner in that space. Core API is not a format so much as a format neutral way of modelling the domain: the format would be Core JSON but, renderers allow outputting to whatever format you like, Swagger, API Blueprint, HAL, etc.

(Core API also has an interest in Hypermedia that we won't go into now.)

Fast forward and Open API is the current champion in the description space so we need to up our game there.

Exactly what that entails for v3.8 we need to see. (Part of that is a review on the Third-Party packages, including drf-yasg, to see where our effort is best spent.)

Update: It looks like we'll roll a maintenance 3.8 (with small BC changes prompting the minor release).

The feature work will then be 3.9. (It's not forgotten: it's just numbers are cheap.)

@axnsan12: You asked somewhere (I can't find it now) about extra API on APIView, for something like get_schema_class.

The answer to that is that I'd (still) rather back-inject that from a custom view descriptor than add it to the APIView API (which is already big enough; schemas are separate, and we want to keep it that way).

So you might do something like:

class CustomViewDescriptor():

    def __get__(self, instance, owner):
            inspector_class = instance.get_schema_class()
            inspector = inspector_class()
            inspector.view = instance
            return inspector

    ...

Note: I don't think I'd do this personally.

Here you have access to method, action and all the rest. The only thing not passed is the routed path, but I'd argue you're in big trouble if your choice of schema generator class depends on that... (Even then, the SchemaGenerator could make that available to the view before fetching the schema if it was really necessary.)

I'm pretty sure the API is sufficient to cover whatever use-cases. I'm open to the possibility of a change of course. But I'd rather steer this way. (APIView really is big enough already.)

I hope that makes sense.