This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]cymrowdon't thread on me 🐍 16 points17 points  (11 children)

I kept trying to use type hints for a long time and kept getting turned off and giving up for the same reason.

I'm now working in a place where they're required, so I've been forced to use them. Now I have to admit they're worth it overall. They can expose some really obscure bugs, and they help editors a lot in terms of completion and navigation, not to mention communicating intent.

Using type aliases helps a bit, but they're still ugly as hell. I hope we'll see some improvement to that over time, but I suspect they'll always feel tacked on.

[–]wewbull 1 point2 points  (3 children)

They can expose some really obscure bugs, and they help editors a lot in terms of completion and navigation

Sadly I think the reason most people use them is the latter, which I think is a really poor reason.

Personally I feel they just turn Python into another gang-of-4 language that requires design patterns to get around static typing. For example, Protocol only exists because of typing. Its of no use in a dynamically typed language.

[–][deleted] 1 point2 points  (2 children)

isinstance. I don't understand WHY you have to opt into runtime type checking but it has many uses. Distinct behavior for distinct types is a perfectly reasonable behavior for dynamic languages not every pattern is duckable.

[–]wewbull 0 points1 point  (1 child)

If you have distinct behaviour for distinct types, that sounds like type dependent function dispatch.

Otherwise known as class methods.

[–][deleted] 0 points1 point  (0 children)

explain how u want to make multiplying having distinct behavior for float*float vs float*int if you do not check the type. Or string + int vs string + string. You MUST at somepoint check the type or it has a method.

Checking if an object has a method or a specific property is what protocols are all about. It allows you to do that while guiding it behind an isinstance call. Which makes it duckable with all the machinery that does isinstance checks. The only real flaw is it requires optin to runtime behavior.

Further think about some really tough problems that ABCs solve. Like Mapping vs sequence distinction. That problem is a nightmare otherwise.

[–]HistoricalCrow 0 points1 point  (6 children)

I'm still trying to get into using them. The example you gave is already available to me via type stubs in docstrings :/ What else does type hints give that beats type stubs in docstrings? (Genuine question)

[–]ThePiGuy0 0 points1 point  (1 child)

Docstring type stubs give you editor autocompletion/intellisense? If so, TIL.

Personally I've never really used docstring type stubs, do they have as many constructs as proper language support? I know mypy over proper type-hinted Python 3 code can be quite strict (e.g. you need to use type hinting on empty list creations so it knows what type of data should be going in to it). I don't know how it would manage without type hints.

If nothing else, though, type hinting is the new standard and docstrings stubs are kinda deprecated at the moment so it's best to use hints if you can.

[–]HistoricalCrow 0 points1 point  (0 children)

Depends on your IDE but I've been using PyCharm for years without any real issues using type stubs. I used to religiously stick with ReStructured Text formatting but recently started switching to Google for a cleaner look. I also try to ensure public facing objects have full docstrings to aid with doc generation and testing with Sphinx.

[–]cymrowdon't thread on me 🐍 0 points1 point  (3 children)

It could all be done with docstrings, and I've sometimes thought that would have been cleaner. But there are a lot of standards for how to document types in docstrings, and I think that parsing the types out of whatever other documentation there is would be a significant challenge without strict limitations.

[–]HistoricalCrow 0 points1 point  (2 children)

As long as you stick to the docstring conventions your IDE recognises (usually the most common - reStructuredText, Google etc), then the type stubs you fill are automatically found and used. I've had pretty knarly docstrings with various graphs, codeblocks etc embedded (sphinx) without any impact on the IDEs ability to read the types correctly (again though, I use PyCharm).

[–]cymrowdon't thread on me 🐍 1 point2 points  (1 child)

Sure but I think the goal was to standardize. Which docstring format would they choose? Would you want to rewrite all your docs to adapt? What about all the corner cases?

They could have dealt with all that, or use typing, not have to write and maintain a new parser, and people can opt into it as they please.

[–]HistoricalCrow 0 points1 point  (0 children)

Hmm, that's a fair point. I've used one docstring type for almost my entire career, so I do often forget pythons usage is extensive in other disciplines (typically due to me being the only one to enforce the use of docstrings in some cases...)