Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python types have an expectations problem

medium.com

Post reply on HN
Print view View original

31–40 of 115 posts

Re: Python types have an expectations problem

#31

Post by olejorgenb »

miohtama wrote: post #5
teddyh wrote: post #3

Summarizing quote: “ Python type hints are a core part of the language, they even have standard library modules (typing), and yet they don’t do anything when used in that language without some external tooling. That, to me, is a bit of an expectations mismatch. ” I.e. they’re complaining that a type checker like mypy isn’t run by default.

It's also good to note that all popular editors and IDEs like Visual Studio Code and PyCharm support type hints quite well by default. Some external tooling needed, but it's your editor and you are going to have any case.

PyCharm unfortunately does not supports type hints fully. It certainly utilize the hints, but there's a bunch of things it simply does not understand which make hinting much less useful when using PyCharm.

Re: Python types have an expectations problem

#32

Post by wodenokoto »

teddyh wrote: post #3

Summarizing quote: “ Python type hints are a core part of the language, they even have standard library modules (typing), and yet they don’t do anything when used in that language without some external tooling. That, to me, is a bit of an expectations mismatch. ” I.e. they’re complaining that a type checker like mypy isn’t run by default.

Not so much that it’s is t run by default but that it doesn’t even exist by default, was my reading of the article

Re: Python types have an expectations problem

#33

Post by robertlagrant »

dboreham wrote: post #26
thadt wrote: post #12

Earlier quoted context omitted.

C's type checker is the MMU - when you mess up types, it give you a segfault. If you're lucky.

Funny, but for the readers who don't know C -- this isn't true. C has type checking at compile time.

It has something, but not what you'd call modern type checking:

  #include 

  int main(void) {
    unsigned int positive_number = -1;
    printf("%d", positive_number);
    return 0;
  }
Prints -1.

Re: Python types have an expectations problem

#34

Post by [deleted] »

teddyh wrote: post #3

Summarizing quote: “ Python type hints are a core part of the language, they even have standard library modules (typing), and yet they don’t do anything when used in that language without some external tooling. That, to me, is a bit of an expectations mismatch. ” I.e. they’re complaining that a type checker like mypy isn’t run by default.

[deleted]

Re: Python types have an expectations problem

#36

Post by sco1 »

sesgoe wrote: post #23
mkesper wrote: post #21

Earlier quoted context omitted.

You could use mypy in pre-commit so code is always checked. Sad there's no per-file switch to tell the interpreter 'this has to be checked'.

Yeah, this is something we tried! And yea, from an IDE perspective, it seems like maybe a sensible default would be to run `mypy ${CURRENT_FILE}` on save or something -- I've tried this manually myself, and it's decent , but it's not good enough to use constantly. I don't remember specific issues since I haven't done this in a long time. Pre-commits are painful (on purpose!), but preventing people from shipping seeme…

Running mypy as a pre-commit hook is a bad idea for many reasons, primarily being a relatively really heavy runtime cost, plus you're running it on the entire codebase since it's going to follow your imports.

Many people, including myself, also like making atomic commits that may not be fully typed yet. Conditioning people to skip the hook(s), doubly so during a gradual typing rollout, just conditions them to skip them always. Leave it in CI where it's checked at a point in time where it actually matters.

Re: Python types have an expectations problem

#37

Post by magnusmundus »

lpapez wrote: post #18
simonw wrote: post #9

"I’d have to set up some CI with the type checking step and make it impossible to deploy the code that doesn’t pass it, maybe." Yes. That's how people successfully use type checking in Python.

I did that for Python, and now I do it for PHP as well. Trivial to set up but ends up being a huge time saver, especially when reviewing junior colleagues code - don't even ping me to review your code until you've managed to convince the static analyzer it will work!

Re: junior colleagues, do you not instead arrive at "why does the static analyzer complain", or worse, an avoidance of proper types that you then have to point out in review?

Re: Python types have an expectations problem

#38

Post by tyingq »

misnome wrote: post #24
tyingq wrote: post #2

There are some other warts also, like hard-to-grok errors if you're using typing syntax that's not yet supported in your version of python. Like: somevar: dict[int, int] = {0: 0, 1: 1} Produces "TypeError: 'type' object is not subscriptable"

Unless you both a) Don't evaluate them at runtime, and b) import annotations from __future__, in which case it is generally safe to write them like this (and AFAIK all of the usual type-checking tools read them fine).

Nope. See https://bugs.python.org/issue45117

Re: Python types have an expectations problem

#39

Post by tyingq »

sco1 wrote: post #10
tyingq wrote: post #2

There are some other warts also, like hard-to-grok errors if you're using typing syntax that's not yet supported in your version of python. Like: somevar: dict[int, int] = {0: 0, 1: 1} Produces "TypeError: 'type' object is not subscriptable"

For context, if others aren't familiar: type hinting generics were added to Python 3.9 by PEP 585 (also available in Python 3.7+ with the annotations future import). PEP 484 previously added type hints to Python 3.5 as explicit imports from the stdlib's typing module. https://peps.python.org/pep-0585/ https://peps.python.org/pep-0484/

Note that the annotations import from future doesn't help with this one.

https://bugs.python.org/issue45117

Re: Python types have an expectations problem

#40

Post by [deleted] »

mg wrote: post #16

I don't really like types on the function declaration line. Instead of this: def check_permission(user: User, perm: str, obj: BaseModel | None) -> bool: I find it much nicer to read something this: """ Check if user is allowed to drive a car :user: User # The application's User model :perm: str # Our magic permission string. Tab seperated. :obj : Basemodel | None # Base model of all our objects since 2017 :returns bo…

[deleted]
Post reply on HN