This creates a new `pyodide.ffi` submodule and adds a bunch of new subclasses of
`PyProxy` to it.
There are three stages in which we are concerned with the behavior of the
objects we define:
1. at time of static typechecks
2. at execution time
3. when generating docs
Prior to this PR, the subtypes of PyProxy only work well for static type checks,
they work acceptably at runtime (just don't let the user access them), and the
docs don't look that great. This PR is primarily intended to improve the docs
for PyProxy, but they also make execution time checks work better: you can now
say `obj instanceof pyodide.ffi.PyCallable` instead of `obj.isCallable()` which
I is easier to understand and to cross reference against the documentation. I am
marking `isCallable` as deprecated.
I also made a bunch of edits and improvements to the docs.
I have deprecated `PyProxyCallable` in favor of `pyodide.ffi.PyCallable` and
`PyProxy.isCallable` in favor of `obj instanceof pyodide.ffi.PyCallable`.
`PyBuffer` has been renamed to `pyodide.ffi.PyBufferView` and a new `PyBuffer`
has been created which is a subtype of `PyProxy`.
This leads to more consistent rendering (functions and methods get parens after
them) and reduces chances of warnings about getting the wrong link. It is also
possible to use `~fully.quallified.name` to just show `name` if we use a specific
reference type, but it doesn't work with `any` for some reason.
Fix various sphinx build warnings.
I removed **all cross-references** in the changelog document. It causes trouble
whenever we make an API change.
For example, Hood did some great work of splitting JsProxy classes into subclasses
in this release, but the changelog of older versions still contains cross-references to
`JsProxy.<method>` which doesn't exist anymore. It doesn't make sense to change it
to e.g. `JsBuffer.<method>` or `JsArray.<method>` as those classes are not available in
that version, so I think the reasonable option would be not using cross-references.
Before we had a single `JsProxy` documentation class. Apparently mypy treated
it as `Any`. It had a bunch of methods on it that may or may not appear in
any specific ` sProxy`.
This does two things:
1. Split up `JsProxy` class into several synthetic subclasses like `JsArray`,
`JsBuffer` etc. These work much better with mypy, they should also improve
documentation layout and it helps when different subclassess have different
methods with the same name (e.g., `JsArray` and `JsMap` both will have `pop`
methods).
2. Make `isinstance` and `issubclass` work correctly both with synthetic `JsProxy`
classes like `JsArray`, `JsBuffer` etc and with `type(an_actual_jsproxy)`.
This cleans up the bootstrapping mess in `_importhook` because the `JsProxy`
from `_core_docs` works fine for instance checks now.
I had to make changes to various other Python files
because mypy now understands the types better and noticed that there were type errors.
For instance, this fixed several minor mistakes in the types in `http.py`.
Gyeongjae Choi