A little frustrated by the lack of types

[macy-kairospower]

This library is incredibly powerful, but the lack of type hinting makes debugging horrific.
Commented return types are not a suitable replacement.

The core of this library is strongly typed, and does no service by pretending otherwise

[carsten-forty2]

Unsure what do you mean ....

Yes there could be always a better documentation, but all arguments for the specific function are at least shortly documented: https://www.pygimli.org/pygimliapi/_generated/pygimli.meshtools.html#pygimli.meshtools.createCube .. probably you can scroll up in your editor popup to see them too? How should it look to fits better for you?

Or do you mean this: https://docs.python.org/3/library/typing.html ?
Which is a relatively new feature in python (since 3.5) and while we already tried some first steps to incoporate them for new functions, it would need a huge effort to add them retrospective.
However, this will not work in generell, since a lot of the pygimli api is supposed to be "flexible" and allows multiple, context depending and non unique argument types, which cannot be expressed by this type hinting.

[macy-kairospower]

I was mostly referring to type hinting for return types of methods. It makes a world of difference for code legibility.

• Child methods all show as un-defined
• Accessing properties of objects requires poring over the documentation
• Intellisense provides no warnings, leading to run-time failures

Export VTK (which is at least partially defined in the source, is nowhere to be seen in the user-facing side.

Even incomplete type hinting is better than none

[halbmy]

I guess you mean type hinting according to PEP484 (introduced with Python 3.5) like

def greeting(name: str) -> str:
    return 'Hello ' + name