Pycharm gives incorrect warning for single-variable shapes?

[zplizzi]

For this example:

from nptyping import Float
from nptyping import NDArray
from nptyping import Shape

def do_thing(thing: NDArray[Shape["Test"], Float]):
    return thing

PyCharm gives a warning:

Am I making a mistake here? I'm trying to specify that the shape has one dimension of length Test. I guess I can replace Test with * test to specify the same thing (arbitrary value, with a label), but the former notation seems neater and seems like it's supported by the BNF.

[ramonhagenaars]

Hi @zplizzi,

There is no mistake on your part: Shape["Test"] is valid and does express the same as Shape["* test"], i.e. a 1-dimensional array of any size (or strictly of size "Test" in the former case).

In this case, PyCharm and also MyPy, in their unparalleled wisdom, deduced that "Test" must be a type of some sort (because what else could it ever be?). Actually - I will now contain my sarcasm a bit - it's because PyCharm and MyPy do not dive deep enough into the typing system of shape.pyi to see that Shape["Test"] is a perfectly fine statement.

What you could do, apart from the solution you yourself already found (👌), is to not use Shape from nptyping, but use typing.Literal instead:

from nptyping import NDarray, Float
from typing import Literal

def do_thing(thing: NDArray[Literal["Test"], Float]):
    return thing

The typing.Literal is accepted by nptyping and always will be and the IDEs and type checkers will be happy about it. To make it look a little nicer, you could alias typing.Literal:

from nptyping import NDarray, Float
from typing import Literal as Shape

def do_thing(thing: NDArray[Shape["Test"], Float]):
    return thing

I'm afraid that is all there is to it for now. If there is any fix that can be done on nptyping's part, I would glady do so or learn about it. It has been quite the struggle challenge for the last months to get to a certain level of acceptance from PyCharm, MyPy and Pyright/Pylance at the same time. I keep my fingers crossed for more maturity on the subject of the Python typesystem for the coming years.

[zplizzi]

Makes sense, thanks for the detailed response! Totally understand the limitations here, mainly just wanted to understand them better in this situation. The alternative you suggest with Literal does seem neater than my solution. Perhaps it would be helpful to add a section to the docs to discuss the current state of compatibility with the common static analysis tools and workarounds for any other common issues like this one. I'd guess most of the people interested in this project will also be using a lot of static analysis :)