Optional Static Typing using mypy

Feature Requests
1

Hi,

I have just been going through the Anvil site and wondered if there are any plans to integrate optional static typing using mypy, at least on the server side?

Thanks & Regards

2

On the server-side, you could use python’s built-in typing module no?
Seems pretty similar.

3

They seem to be two different things. From the very top of the documentation you linked to:

Note
The Python runtime does not enforce function and variable type annotations. They can be used by third party tools such as type checkers, IDEs, linters, etc.

The typing module allows us to tag variables and functions with types, but Python does absolutely nothing with them. We need a type checker like MyPy to enforce those types.

I stumbled across this older thread looking for this exact feature. Just a little bit ago, I spent 20 minutes trying to figure out why strptime wasn’t working even though my format string was correct. Then I realized I had flipped the arguments. :man_facepalming:t3:

Type checking would be very, very helpful.

4

Nice clarification @lee

type hints in the client are unlikely to be supported any time soon
here’s a related post on skulpt (Anvil’s client side python interpreter):

type hints on the server is supported in full python 3 (since it runs python 3.7)
so you could clone your app to your local machine and run mypy on all your serverside code…

1 Like
5

I ran into this issue while attempting to get previously-written, type-hinted code running client-side. I wanted to still be able to use and type-hint my code in non-Anvil projects.

I’d be interested in learning if there’s a better way to address this than the approach I took (and please tell me if the approach I took was a terrible idea).

I converted imports like

from typing import Dict, List, Optional

to instead read:

try:
    from typing import Dict, List, Optional
except ImportError:
    from .faketyping import Dict, List, Optional  # type: ignore

and I then created a faketyping module with blank class definitions, e.g.:

class Dict:
    pass
class List:
    pass   
...

Doing that at least got rid of exceptions for code like:

def foo(bar: List[str]) -> Optional[str]:
  ...do stuff...

I did still encounter problems for type hints such as Optional[str] , when used in statements (i.e., not in function definitions). For example,

baz: Optional[int]=2

would still raise an exception. So, in those cases, I did need to switch over to comment-style type hinting as recommended on the Skulpt fourm. So the above would become:

baz=2 # type: Optional[int]

Nevertheless, since most of my type hints were in functions, I was able to avoid a lot of rewriting (I find the comment-style type hints less readable, especially for functions).

Of course, I’d very much like to hear from anyone more knowledge than myself about whether the tack I took was reasonable, or if I’m courting disaster (or somehow incurring performance penalties).

Plus, if my kludgey approach wasn’t an absolutely terrible idea, I was also considering implementing an even kludgier one, in order to make baz: Optional[int]=2 pass muster!

Namely, in faketyping, instead of writing:

class Dict:
    pass

I was instead thinking of writing:

class OptionalFakeClass:
   def __getitem__(self, x):
       pass
   def __setitem__(self, x, y):
       pass
   def __delitem__(self, x):
       pass 

Optional=OptionalFakeClass()

Is this crazy? Is there a better way to prevent Anvil from complaining about client-side type-hints that are permissible with CPython and typing? The above does seem to work okay, per my limited testing. And since the hack’s ugliness wold be fairly well-contained, I’d find it worthwhile, since it’d mean other areas of my code would be cleaner and type-hinted. But that’s only if I I’m not somehow risking catastrophe.

Any thoughts very are very much appreciated!

-Dan

1 Like
6

related PEP 585 -- Type Hinting Generics In Standard Collections | Python.org

The above pep is in progress in skulpt. So hopefully this will get added at some point and then adding the typing module probably would be a bit easier from there.

Similarly fully implementing type annotations for classes and modules is also in progress.

What you’ve done as a work around seems sensible to me.

3 Likes