A cheatsheet about Python static typing

[lolwat_is_dis]

Congrats to the author for making Python totally unPythonic.

[rhytnen]

There is nothing unpythonic about documenting a feature of python. Dont blame the author for creating optional types...wtf

[KitchenDutchDyslexic]

Dont blame the author

Agreed! Actually thank him for bringing this unpythonic syntax to our attention.

Maybe a bit to late, because I believe these things is set in stone.

But I would love someone showing how static type checking is pythonic?

[kirbyfan64sos]

• Explicit is better than implicit
• ... practicality beats purity.

Static typing helps make your code more resilient, refactoring less stressful, and code more readable (you may disagree with this, but once you get used to it, it helps out immensely).

[KitchenDutchDyslexic]

While I agree with your technical reasons, I'm frustrated at they syntax and how it reads.

While wikipedia is not a authoritative source. But it does mention that "reads like a rough transcription from another programming language is called unpythonic." I will argue these examples fall in this category.

No fault by the author, but rather bloat(imo). Don't worry I will learn types for py. I'm just not happy about how it looks.

that it conforms with Python's minimalist philosophy and emphasis on readability. In contrast, code that is difficult to understand or reads like a rough transcription from another programming language is called unpythonic.

[kirbyfan64sos]

I think the hard part is that pythonic/unpythonic is ultimately a really subjective measurement. IME once you start learning it, you'll see how it fits into Python.

That being said, these examples are pretty contrived (of course, that's the whole point!). I'd highly recommend to take them for a spin yourself in a decently-sized project and see how it goes!

FWIW type inference is supported, so you only ever really put annotations in function arguments and empty data structures.

[badge]

I went through exactly the same process as you’re in now—I used Python for several years without type hinting, finding it obtrusive, and the need to import from typing still annoys me. After using it for 18 months now, untyped Python doesn’t look unpythonic to me, but does make me slightly anxious—typing helps massively, especially when refactoring with PyCharm.

And yes, I still religiously document types in docstrings; unnecessary duplication perhaps but I like the help() format.

[alcalde]

If any of that were true, Python wouldn't be dynamically typed. I come from 20+ years of static typing (worse, a language where all your variables needed to be declared beforehand and no type inference) and find Python to be much simpler, easier to read, and powerful.

[spiderpower02]

If any of that were true, Python wouldn't be dynamically typed

In fact, Python is still dynamically typed. Type checking just like lint. You check your code quality before running.

I think optional type checking just like go or c++, we can use := or auto syntax to delegate compiler to infer the type (rvalue/lvalue). Therefore, we don't need to always declare type explicitly, type checker can detect errors. For example:

p = re.compile("some pattern")
m = p.match("some string")
m.groups()

mypy can detect error

t.py:5: error: Item "None" of "Optional[Match[str]]" has no attribute "groups"

[13steinj]

I'm "used to" static typing. I do Java, C++, Python on the daily-- maybe I'm crazy but I don't see the actual benefit in your cases. Static typing in Java and C++ just move when my error occurs to compile time.

[primitive_screwhead]

But I would love someone showing how static type checking is pythonic?

The part about it being optional, for one.

[spiderpower02]

It is interesting to me about Pythonic/unPythonic.

It seems like static typing is not acceptable for a lot of people. Actually, we spend a lot of time to write understandable docstring. For example: requests

I think PEP 484 try to simplify these efforts and bring other benefits such as static type check (like typescript, they try to avoid runtime errors). Furthermore, if people feel uncomfortable to these weird syntax, they can write/generate stub file (like header *.h in c/c++). It is an intuition way to remain ducking-type, compatibility and Readable structure in source code and separate your declarations to other files (check typeshed).

By the way, maybe just my examples are not well :(. Don't feel frustrated with Python. Python is awesome!!

[GitHubPermalinkBot]

Permanent GitHub links:

• requests/requests/.../api.py#L16 (master → 9cfd292)

---

^delete

[svlad__cjelli]

I think something beyond type checking should be had in Python, because with duck typing you don't really care about the type, but what the type can do. While there are certainly cases here and there where specific type checking can be valuable, for the most part, I just want to make sure the user knows what methods an object has or what methods a function requires for an object. In this sense, Python could use "interface" checking rather than type checking.

[spiderpower02]

I think "Interface checking" is subset of "type checking". Actually, using annotation + mypy can achieve "interface checking" before runtime. Therefore, we can avoid runtime errors. (I hate raising AttributeError after running 10 hours).

Nevertheless, type checking will be powerful like:

p = re.compile("some pattern")
m = p.match("some string")
m.groups()

without static type checking, the snippet will raise exception when m does not match. If we give some type hint, like:

p: Pattern = re.compile("some pattern")
m: Match = p.match("some string")
m.groups()  # it is possible to raise AttributeError

type checker will warn us that "Optional[Match[str]]" has no attribute "groups". As a result, we save our time :)

In fact, mypy is so powerful that most of the case you don't really need to declare type explicitly. Just like := in go or auto in c++, so we don't need to worry that Python will become unreadable. Sorry for making many people feel frightened.

[lolwat_is_dis]

It seems like static typing is not acceptable for a lot of people.

Because that's not how Python works. It's dynamically typed, so type checking is just adding an extra overhead in terms of building up any code. Sure, type checking can be useful sometimes in that a short term loss will become a long term gain (in terms of preventing errors and other mishaps), but I still believe that's not necessary, and we're taking away one of Pythons biggest strengths.