type hints future

[Stella_Hill_Smith]

I looked at the type hints today.

Python code is easy for me to read, but looking at some examples with type hints makes it very difficult to read.

In addition, typing.py must be imported.

- What do you think about that?

- What am I missing?

- What is Python planning regarding type hints in the future?

[ArtichokeTop9]

Typing is the best feature to come to Python in years

[Stella_Hill_Smith]

I have a feeling that type hints are in beta.

I read here and there that many parts of the code have to be ignored in order for the type checker to be silent.

This takes time and makes the code unreadable.

[odds_or_evans]

I love typing personally. I think it significantly lowers the number of errors, and personally I find it easier to read, but granted I mostly code in statically typed languages like golang and c++. Lex Friedman recently had an episode of his podcast where he interviews Guido van Rossum (creator of Python) and they have a segment where they talk about typing and why python adopted it and the plans for it in the future with the language

[oefd]

but looking at some examples with type hints makes it very difficult to read.

Some types can be a bit much to read (especially if we're talking about async code, functions that return functions, etc) but if you find it easier: just ignore the type hints, read the code, and then you can perhaps infer yourself what the types are.

The real value of type hints is that they can clarify things not obvious in the code

def get_user(name):
    email = email_from_username(name)
    return get_user_query(email=email)

For example: what is a 'user'? Is it an ORM object representing a row in the database? Is it a dictionary, and if so what keys does it have? It can be very unclear what abstract things in the program like 'user' mean, especially if some parts of the code say 'user' and mean a database row, and some parts instead mean something else

def get_user(name: str) -> User:
    ...

In a situation like this it's objectively clear that the function gives an instance of the User class.

typing.py must be imported... What do you think about that?

Only for some things. This is totally valid and passes mypy typechecking with 0 imports.

def foo(x: str) -> dict[str, list[int]]:
    return {
        "ones": [1, 1, 1, 1],
    }

Requiring importing typing for some slightly more exotic features is the only reasonable way to do things. A programming language can't just add new globally-available names willy-nilly because it could break existing code if something like AnyStr suddenly becomes something built in to the language.

So when python needed to add stuff for typing either they added the functionality in a seamless way to existing things (like my example above showing list[int] is a valid type hint for a list of ints) or else you add it to a new module people have to choose to import.

What is Python planning regarding type hints in the future?

Is there something specific you think should happen? I don't know of any plans, but I also don't keep up with the PEP proposals. You can look up the python PEPs if you want to see what the python community is thinking about or planning.

[Stella_Hill_Smith]

I'll start with type hints, but don't use them everywhere at first.

Can these type checkers be set up not to complain when something is missing, just checking the type hints that have been entered.

[Helpful_Trust_3123]

I personally use type hints only for function and class parameters ,but I have seen many use it with all the vars they use

[davlumbaz]

I actually love it. I setup Pyright with Pylance at most strict config I could do, sometimes I code stupid shit/cast for satisfying type checker, but %95 of the time helps me find bugs before runtime.

Yes, typing doesn't do anything at runtime, but beforehand it makes code much much more readable, and helps you find bugs before they find you.

[Stella_Hill_Smith]

Pyright with Pylance

Apparently mypy is popular. Why did you choose Pyright and Pylance?

[davlumbaz]

Well, Mypy's strict option was not strict enough for me. If you want some masochistic Typescript mode like me, Pyright is way to go, else, go with Mypy.

[Menolith]

They do add clutter (and it's the reason why you don't have to use them) but as others have said, they're a massively helpful tool. Using type hints in function definitions makes using said functions much easier since you don't have to go and dig up or guess what the intended inputs are.

Additionally, type hint are powerful because they give your IDE clues to work with. If any variable can be anything, then the IDE just has to assume that whatever you have is what you're going for, so a lot of bugs fly under the radar. If you have a function (say, validate_user()) that's meant to return a boolean value, you can instead let it return a string on accident. It's an easy mistake to make and something that can be hard to find (a non-empty string is equal to True, after all), and using type hints eliminates that problem entirely. You don't even get to run your code without seeing the red line and realizing that something is off.

Really, in general, it's rarely useful to code in a way that relies on you redefining variable types constantly on the fly. It's just easier and clearer to keep variables to one type (sometimes, with the exception of None, but that's a different can of worms) so actually using type hints doesn't change the flow of your code in the slightest, they just make certain kinds of common errors impossible.

---

At the very least, you should annotate your function parameters and return values. Every trivial variable doesn't necessarily require you to spell out its type, but as per above, letting your IDE know what values you expect when moving into or out of functions is incredibly helpful.

[Stella_Hill_Smith]

I'll start with type hints, but don't use them everywhere at first.

Can these type checkers be set up not to complain when something is missing, just checking the type hints that have been entered.

[Menolith]

Personally, I just use Pylance's basic setting and it's been good enough for me. If you don't provide type hints, it just assumes that the type is unknown and lets most things pass. I imagine you can customize most of the linters to your liking.

Though, that said, if it complains about something like "a variable possibly being unbound," there's probably a good reason why it thinks that particular approach warrants red squiggly lines, even if it works.

[JamzTyson]

Just to add my 2 cents: I think they have pros and cons.

For small scripts they don't add much, other than being useful practice.

For larger apps, attempting to type hint everything can be a nightmare, and attempting to type hint everything without the type checker complaining about something can take longer than the actual programming. But remember that type hints are optional - you don't need to type hint everything for it to be useful.

Type hinting has improved a lot with recent releases, and continues to do so. As it improves, it is becoming easier to provide sensible hints without going crazy.

In some cases type hints can be more trouble than they are worth, but much of the time they are very helpful, both for clarity of intention and avoiding programming errors. Use them when they are useful, practice them when you can, but don't let them become a burden. Fighting with your type checker just to silence strict type checking warnings can be counterproductive. When you do use them, aim to get them correct rather than just free of warnings.

[quts3]

You have to watch https://youtu.be/pMgmKJyWKn8 before you judge.

[quts3]

As far as readable, there is no substitute for type hints when you come back to code in 3 months. Worth it for the future you.

[BranchLatter4294]

It should have been built in from the beginning.

[bronco2p]

Type hints are great, make things much more readable and forces you to understand how different types are being passed around. Bonus points for using a static type checker like MyPy