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

591–597 of 597 posts

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

#591

Post by saila »

nine_zeros wrote: post #585
saila wrote: post #577

Earlier quoted context omitted.

Learning any new syntax, feature, etc takes time. IME learning type annotations can pay major dividends. For example, I wrote some type-annotated code the other day and mypy pointed out a couple places where I was passing the wrong type, which saved me from having to fix those bugs later, thus saving time for "actual work."

There is a recurring cost to complex type annotations and that is that every single developer working on that repo (could be thousands) has to unravel the complex types, their aliases and the instance objects to modify any code. This as opposed to a legitimate type system where complex types are classes themselves which don't need unraveling. There is no need to alias a type and there is no need to maintain separate…

I agree that complexity could be an issue with Python's typing, which has some flaws, although it's been improving.

Type aliases are okay if they're not overly complex, having used them in Python and other languages to good effect, e.g. to avoid duplication or for clarity.

I'd suggest using type annotations where it's not overly onerous--which is probably most places--to get the benefits without much effort but perhaps avoid them or use simplified types where it's too complex.

I also agree that there are places where typing is unnecessary and doesn't add much value, such as in certain scripts.

Like many things in programming, it's all about finding the right trade-offs.

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

#592

Post by captainmuon »

just-ok wrote: post #499
captainmuon wrote: post #330

Earlier quoted context omitted.

Do you know if there is a way to do runtime type checking in the whole program with typeguard, beartype or something else? As far as I know you have to go through and add decorators manually. Typeguard had a profiler hook that almost got it right, but is being removed. Ideally I would want to say 'python3 -m typecheck myprogram.py' and it would run typechecking everything in my code (but maybe not in library code).

I believe you're describing MyPy? http://mypy-lang.org/

MyPy is great but it checks "offline" or "at compile time" if you know what I mean. It is like a super linter, and doesn't actually run the program (AFAIK).

What I'm looking for is more like a debugger or profiler. It actually runs the program, and then reports if at any time the type annotations deviate from the actual types. (I guess the general case is too costly - think of typechecking a huge list - but for most cases it should be possible.) There are runtime type checkers for python, but the all require modifying the code, and they don't work properly on the main module.

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

#593

Post by the_af »

dragonwriter wrote: post #502
the_af wrote: post #73

Earlier quoted context omitted.

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

> So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.

As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool.

In my opinion, of course.

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

#594

Post by smitty1e »

tjoff wrote: post #556
kadoban wrote: post #477

Earlier quoted context omitted.

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

That line of reasoning doesn't make any sense to me. If the author / last person who touched the code misunderstood it then there is a 100% chance there is a bug here. Knowing that off the bat is quite helpful. And it also tells something about the code quality if it is a common occurrence.

Could be an indicator to look up the file in git log.

Which need would send me back to pypi to look at other prior art, if possible.

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

#595

Post by xvmodvx »

I'm sorry, but I'm writing this response without reading all the previous comments, but with almost 600 directly to it and more comments to a comment I hope it's understandable.

However I did read a good portion of them and I'm confused...I thought Python doesn't use types everything is an object according to their documentation.

Now for my 2 cents, if you don't care, don't read it... a lot of the comments aren't based on facts but opinions and a lack of understanding of the actual language, funny that I write that after my previous sentence huh? :) . Every language has goods and bads, don't think as someone who as a Python programmer or C programmer, just a programmer and use the best tool for the task you're trying to complete. If you've been programming for awhile you should have used a dozen different languages at some point. Don't focus on what the language can do but understanding the underlying concepts and then you can easily use the one that makes the most sense for that project.

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

#596

Post by tezzy »

foepys wrote: post #435
bayesian_horse wrote: post #422

Earlier quoted context omitted.

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python... In my opinion there is no excuse not to.

What you both are experiencing is your bubbles clashing.

I have been developing almost exclusively in Python for the last 4 years (occasional C#, Java and PHP) and although my entire team disparages PHP it is really quicker and fewer characters for most stuff.

Luckily IDEs can auto add the imports, but sometimes a slightly mistyped piece of code auto adds an import I need to delete, I love avoiding imports and circular imports in PHP. The other nice thing is avoiding random python behaviour differences in MacOS, Windows and Ubuntu. Code that works fine in CircleCI but not locally. Works on a Mac but not on windows etc… I didn’t experience that with PHP.

Not sure there are a huge number of long term PHP devs who switch to Python or the other way around to have a reasonable opinion.

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

#597

Post by tezzy »

saila wrote: post #495
bayesian_horse wrote: post #289

Earlier quoted context omitted.

Have you tried it? Python has gained most of its popularity before type hints, and I would (wildly) guess 99% of Python programmers don't even use type checking at all. Static typing is completely viable and I hear those arguments mostly from those who didn't use Python for a long time. The added productivity makes up for a little more debugging while the program is running. I'd also posit that many Python codebases…

I'm not sure I'm following your comment correctly, but you seem to be implying that adding type hints in Python results in some lost productivity? If so, I would counter that adding types isn't particularly onerous and adds very little overhead to development time, and over time they'll tend to increase your productivity since you'll make less errors, IDEs can give you better hints, etc. As to the percent of Python d…

I disagree, dependencies can change causing types to change which requires you to alter hundreds of lines across multiple repos.

Each new line or character is a line to maintain, there is a cost associated with that. Tests have costs but are extremely valuable, they are a no brainer to me, types are way less obvious.

I have spent a lot of time maintaining python types. I have no idea how many bugs it has prevented. I am not sure it is a large number.

I know there have been bugs in types, bugs in mypy and dependency changes which created work which only existed because types were in place. There have definitely been days worth of types maintain.

There are the extra type imports, extra time to run tests and integration tests etc.

It is not as straightforward as you might initially assume.

Post reply on HN