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

Python’s “type hints” are a bit of a disappointment to me

uninformativ.de

Post reply on HN
Print view View original

471–480 of 597 posts

Re: Python’s “type hints” are a bit of a disappointment to me

#471

Post by animal_spirits »

wheelerof4te wrote: post #469
mountainriver wrote: post #233

Earlier quoted context omitted.

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?

If you find that you are returning silly types like that, then it is an indicator you are writing your function badly and should refactor it to be simpler

Re: Python’s “type hints” are a bit of a disappointment to me

#472

Post by ImprobableTruth »

zmgsabst wrote: post #351
ImprobableTruth wrote: post #253

Earlier quoted context omitted.

I think I might not have been clear: this is not a limitation of the type system , but of a specific type checker (mypy), that will hopefully be fixed soon. Both Pyright and Pyre support recursive type aliases right now . Open one of their playgrounds and you'll see that the following, intuitive definition JSON = Union[ None, bool, int, float, str, List['JSON'], Dict[str, 'JSON'], ] works without issue. >In fact, you…

> this is not a limitation of the type system, but of a specific type checker (mypy), that will hopefully be fixed soon > Sure, but that's just because the standard library (for now?) doesn't offer deserialization with runtime validation. > it's just the tooling that is lagging a bit behind at the moment So… the standard library has exactly the problem I articulated, and you’re violently agreeing while speaking down…

Your initial statement was that the type system was a poor architectural choice because it doesn't support standard python idioms. To the best of my ability I've tried to communicate that there's an important difference between the type system and the standard library, that one can make it work and that the situation is not worse than most other typed languages.

If you think that's violently agreeing and talking down to you, then there must be some communication barrier that I don't know how to overcome.

Re: Python’s “type hints” are a bit of a disappointment to me

#473

Post by rwmj »

CraigJPerry wrote: post #445
rwmj wrote: post #362

Earlier quoted context omitted.

The number of times I've stared at some random Python function deep inside a library wondering what does this function return ? Even the docs often don't say.

Would you be able to share an example of this? I took a random stab in pandas but they’ve adopted type annotations so that defeats the point. So i thought old-school code bases - zope sprang to mind, but that’s not a good example either because they use docstrings and it’s kind of obvious. So i tried gunicorn on a whim and they have even more attention spent on their docstrings. I just want to sample this feeling of…

I was actually looking at urllib3 yesterday trying to work out the return value from HTTPConnection.connect which calls this _new_conn function internally:

    def _new_conn(self):
        """Establish a socket connection and set nodelay settings on it.

        :return: New socket connection.
        """
  ...
        try:
            conn = connection.create_connection(
                (self._dns_host, self.port), self.timeout, **extra_kw
            )
  ...
        return conn
(I've chopped it down a bit to emphasise the important bits)

What's the type of "conn"? It certainly wasn't clear to me that it's a socket.

But just now I looked at upstream and I notice they've added type annotations, which do greatly improve things:

https://github.com/urllib3/urllib3/blob/e16beb210c03c6f5ce4e...

    def _new_conn(self) -> socket.socket:
  ...
So a small victory for type annotations there.

Re: Python’s “type hints” are a bit of a disappointment to me

#474

Post by wheelerof4te »

animal_spirits wrote: post #471
wheelerof4te wrote: post #469

Earlier quoted context omitted.

Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?

If you find that you are returning silly types like that, then it is an indicator you are writing your function badly and should refactor it to be simpler

That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list.

What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union.

I'll leave it to you to write that Union "type".

Re: Python’s “type hints” are a bit of a disappointment to me

#475

Post by eweise »

Spivak wrote: post #460
eweise wrote: post #446

Earlier quoted context omitted.

Why not just use a statically type language? I really don't understand why python is so popular outside of a few specialized areas.

Because ecosystems are what makes people productive and languages are just a means to access them. Python's ecosystem is absolutely massive and high-quality.

Most popular languages have massive ecosystems. Don't see Python's being a differentiator except for a few specialized areas. In fact, the project I'm on runs on spark wrapped by python libraries, so really its the scala libraries that provide all the heavy lifting.

Re: Python’s “type hints” are a bit of a disappointment to me

#476

Post by Spivak »

nine_zeros wrote: post #470
Spivak wrote: post #459

Earlier quoted context omitted.

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

My codebase is more complex than str, text, dict, int, bool. So developers are creating complex custom types with union[custom_type_1, custom_type_2] where each custom type could have more unions of other custom types. These custom types then get imported everywhere. It is utter garbage.

I don't follow. So some 3rd party library will define a type like Routes = Union[RouteSet, List[Union[str, Route]]] and this is bad? The complexity is already there, you just don't want to see it?

Re: Python’s “type hints” are a bit of a disappointment to me

#477

Post by kadoban »

tjoff wrote: post #329
kadoban wrote: post #240

Earlier quoted context omitted.

The types on stitty-documented code often do depend on the types actually being checked though. Otherwise you need to author to be diligent in their types, but if they're bad in their other docs, that seems unlikely.

You don't think that "the author thought that this function would return X, but I got Y" is useful?

Only for archeological, and maybe sometimes psychological investigations of code.

Re: Python’s “type hints” are a bit of a disappointment to me

#478

Post by zackees »

wheelerof4te wrote: post #469
mountainriver wrote: post #233

Earlier quoted context omitted.

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

Yeah, especially types like: List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]] Oh, so I am supposed to make my own data structures now, just for typing? How about no?

No post body was provided.

Re: Python’s “type hints” are a bit of a disappointment to me

#479

Post by zackees »

wheelerof4te wrote: post #441
gilbetron wrote: post #415

Earlier quoted context omitted.

On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot…

How is typing productive in large codebases? If I see a bunch of imports related to typing only, I have to juggle them around in my mind together with stuff that really matters. Not to mention the notorious circular import problem, that is much more likely in a big codebase. If I have a custom class, that class has to be passed as a type hint for functions. What If I use that class in another module, but have to impo…

No post body was provided.

Re: Python’s “type hints” are a bit of a disappointment to me

#480

Post by oriolid »

wheelerof4te wrote: post #444
rwmj wrote: post #362

Earlier quoted context omitted.

The number of times I've stared at some random Python function deep inside a library wondering what does this function return ? Even the docs often don't say.

Well, the author of that undocumented function maybe did not mean for it to become widely used. There are a lot of "libraries" people write for their use only, who then put them on Github as a token of good will. You as a user of someone else's library can either contribute to it or learn to use it. Otherwise, write your own equivalent.

> Otherwise, write your own equivalent.

And be judged for wasting time reinventing a wheel?

Post reply on HN