What is Pythonic Typing for "There exists some plugin that provides an Adapter for X"

So starting to think about a PyOpenGL 4.x release, which would be first to drop Python 2.7 support, so the first one where type-hints can be used to declare metadata for type-coercion (vs the current nonstandard type declarations). The first big question that comes up is:

Given an open collection of types {A,B,C,...}
And a set of run-time-registered adaptors {E,F,G,...}
Such that a given adaptor may adapt (and must declare the adaptation of) some set of types to interface I
How does one type-specify the arguments that accept one of {A, B, C, ...} which is an open-ended set, and where individual types are not guaranteed to support any common interface (without an adaptor; for instance, between an int, a numpy array, and a ctypes pointer)?

Or, in another formulation:

How do I specify that the type X must have a functor XI in the set Y mapping X => I in order to be accepted?

I *think* the common solution in Python typing would be to require that at some point during imports all adaptors be registered (in normal operation they are mostly loaded on package import), and at that time construct a named, non-open-ended set {A,B,C,D} which is then used by all functions which need to reference the set of types which are supported. What that doesn't allow is cases where someone wants to register adaptor Q for external type R during run-time. That's a relatively rare case, and someone doing so might reasonably be expected to register their plugin before main-code imports.

Alternately, I suppose the type-declaration could be to a *mutable* type-set, but I'm guessing that tools would *not* like that.

Then I guess I'll need to see if multi-dispatch is mature enough (and fast enough) to allow for expanding values based on introspection of other parameters (e.g. where we want the dimension parameters introspected from an array parameter *unless* someone explicitly passes them), or whether we still need our accelerator wrappers to do those operations.

Then I guess we'll see how to make the type-system more *useful*, so e.g. have it catch situations where a 3x3 matrix is needed but you've passed a 2x2 matix, but then *also* allow for the weird-and-woolly situations in OpenGL where you have strided arrays, id-or-array-offset values passed where arrays normally would be, arrays that can be different sizes depending on a flag parameter, etc. Or maybe we'll just punt on that and accept that OpenGL really doesn't *have* a type system other than "C primitives".

Comments

Comments are closed.

Pingbacks

Pingbacks are closed.