Interrogate limitations

[WMOkiishi]

Rationale

Currently, the type stub package for Panda3D uses the panda3d.interrogatedb interface to programmatically generate .pyi files containing type information for Panda's C++ interfaces. Eventually, we hope to package these files alongside the main Panda3D package. Currently, however, the interrogate interface has some limitations that would make maintaining the stub generation scripts alongside the main package a burden.

Limitations

These are the limitations I've come across using panda3d.interrogatedb to generate type stubs. We can check items off the list as they're either addressed or determined to not be fixable or worth fixing.

• Lots of things included in the interrogate database aren't actually exposed to Python.
• The names of Python wrappers for functions, classes, and other objects have to be reconstructed. By default this is a simple process, but there are many special cases where it's not.
• Knowing whether or not a method takes a self parameter is a bit vague. Usually, it's listed if it's present, but other times it isn't.
• Determining whether a class has __copy__ and __deepcopy__ methods added to it is a bit of a hassle.
• There's no way to know whether a function uses Python's special *args/**kwargs parameters.
• Anything typed as a PyObject* has no information as to what kind of Python object it should be.
• The ordering of a function's overloads doesn't always match what a type-checker wants.
• There are cases where a function has multiple signatures that could be condensed into one.
• Finding which types can be implicitly coerced to which other types has to be done manually.
• The fact that the interrogate database is exposed to Python only though a collection of functions with really long names was enough of a hassle that I built my own object-oriented wrapper around it.