Live data from Hacker News

Python developers are embracing type hints

pyrefly.org

41–50 of 581 posts

Re: Python developers are embracing type hints

#41
post #28
post #22

Earlier quoted context omitted.

It's not even close compared to working with Java or Go or any language built with static typing in mind. To be clear, I'm not opposed to type hints. I use them everywhere, especially in function signatures. But the primary advantage to Python is speed (or at least perceived speed but that's a separate conversation). It is so popular specifically because you don't have to worry about type checking and can just move.…

But TypeScript erases (its) types at runtime, exactly like Python. Python is Python's TypeScript. Whether you want TS or JS-like semantics is entirely dependent on whether you use a type checker and whether you consider its errors a build breaker.

I'm not sure what you're trying to say here. If you mean Python's type annotations are erased at runtime... Okay? It still has runtime type information. It's not "erasure" as that term applies to Java for example. And Typescript compiles down to JavaScript, so obviously it's runtime behavior is going to be the same as JavaScript.

In my view it's always a mistake to try and tac static typing on top of a dynamic one. I think TS's approach is better than Python's, but still not nearly as good as just using a statically typed language.

Re: Python developers are embracing type hints

#43
post #29
post #8

Earlier quoted context omitted.

I worked on a project that did this. Drove me absolutely nuts. It's like having all the worst parts of a dynamic language and a static language with none of the benefits. I'd much rather just work in a statically typed language from the start.

I too would much rather work in a statically typed language, but sometimes you have to work with what you’ve got. These systems are part of the core banking platform for a bank so I’d rather some initial developer friction over runtime incidents. And I say initial friction because although developers are sometimes resistant to it initially, I’ve yet to meet one who doesn’t come to appreciate the benefits over the cou…

I'm not opposed to type hints, I use them everywhere. It's specially the strict linting.

But it's a fair point. If you truly have no option it's better then absolutely nothing. I really wish people would stop writing mission critical production code in Python.

Re: Python developers are embracing type hints

#44
post #8
post #6

I enforce strong types on all Python code I’m responsible for - and make sure others don’t play fast and loose with dict[str, Any] when they could use a well defined type. Doing otherwise is just asking for prod incidents.

I worked on a project that did this. Drove me absolutely nuts. It's like having all the worst parts of a dynamic language and a static language with none of the benefits. I'd much rather just work in a statically typed language from the start.

Always fun to inherit a data-scientist derrived chunk of pytjon code for which every type hint is 'takes a dataframe' and 'returns a dataframe'..

Re: Python developers are embracing type hints

#45
I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams.

Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As long as it is an iterable (defined by methods, not by type) you can use it anywhere you want to. Want to create a data object that maps any hashable type to just about anything else? Dict has you covered! Put anything you want in there and don't worry about it.

If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen, so I've sacrificed my developer experience for an unfulfilled promise.

If I wanted to use a strongly typed language I would, I don't, and the creeping infection of type enforcement into production codebases makes it hard to use the language I love professionally.

Re: Python developers are embracing type hints

#46
post #11

Earlier quoted context omitted.

With the newest Python versions, most of the time I don't need typing imports!

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

> hoping for an Unknown someday

Wouldn't that just be `object` in Python?

Re: Python developers are embracing type hints

#47

I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams. Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As lon…

> Need to iterate over a collection of things?

Iterable[T]

> Want to create a data object that maps any hashable type to just about anything else?

Mapping[T, U]

Re: Python developers are embracing type hints

#48
post #4

I recently had to debug someone else's Python code and trying to figure out what variables are was a massive headache, especially coming from C++.

I do not program that much in python, but I believe the general accepted wisdom in dynamic languages was explicit name and load of documentations (as comments and docstrings).

> explicit name and load of documentations (as comments and docstrings).

Which can be out of date are often missing. Might as well use type-hints that can be statically checked.

Re: Python developers are embracing type hints

#49

I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types as I got older. But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show t…

My love for python was critically hurt when I learned about typing.TYPE_CHECKING.

For those unaware, due to the dynamic nature of Python, you declare a variable type like this

    foo: Type
This might look like Typescript, but it isn't because "Type" is actually an object. In python classes and functions are first-class objects that you can pass around and assign to variables.

The obvious problem of this is that you can only use as a type an object that in "normal python" would be available in the scope of that line, which means that you can't do this:

    def foo() -> Bar:
        return Bar()
    
    class Bar:
        pass
Because "Bar" is defined AFTER foo() it isn't in the scope when foo() is declared. To get around this you use this weird string-like syntax:

    def foo() -> "Bar":
        return Bar()
This already looks ugly enough that should make Pythonists ask "Python... what are you doing?" but it gets worse.

If you have a cyclic reference between two files, something that works out of the box in statically typed languages like Java, and that works in Python when you aren't using type hints because every object is the same "type" until it quacks like a duck, that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. To get around this, the solution is to use this monstrosity:

    if typing.TYPE_CHECKING:
        import Foo from foo
And that's code that only "runs" when the static type check is statically checking the types.

Nobody wants Python 4 but this was such an incredibly convoluted way to add this feature, specially when you consider that it means every module now "over-imports" just to add type hints that they previously didn't have to.

Every time I see it makes me think that if type checks are so important maybe we shouldn't be programming Python to begin with.

Re: Python developers are embracing type hints

#50
post #26

I recently had to debug someone else's Python code and trying to figure out what variables are was a massive headache, especially coming from C++.

In Python, every variable is either defined or imported in the file in which it's used, so you always know where to find it. (Assuming you don't do `from foo import *`, which is frowned upon.) In C++, a variable might be defined in a header or in a parent class somewhere else, and there's no indication of where it came from.

How does this help when trying to determine the parameters a function takes? You have to either hope that the name is descriptive enough or that the function is well-documented. Failing that, you need to read the code to find out.
Post reply on HN