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

361–370 of 597 posts

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

#361

Post by shultays »

wronglyprepaid wrote: post #71

How is a grype with static typing that it is not enforced at runtime? This comes up like once a week, have these people never used statically typed languages? > The fact that you can put nonsensical types wherever you want and still get a working program has consequences. Working is questionable, but nothing in C++ prevents this at runtime either, nothing in JVM prevents this at runtime, static typing is not runtime…

Difference between any and object, void* and interface{} is you can't really do anything with the second. Sure you can store something on an "object" type but you need to cast it back to do anything which discourages usage of it (and add runtime checks, usually)

While in python you can mark something as "any" and continue using it as is.

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

#362

Post by rwmj »

bayesian_horse wrote: post #304
smohare wrote: post #300

Earlier quoted context omitted.

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately. The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re hav…

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…

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.

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

#363

Post by kgbcia »

linsomniac wrote: post #180

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever. My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that…

same, started using Objects and Classes more to get type hint support

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

#364

Post by tonyg »

kortex wrote: post #326

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…

> My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks.

Christ. What a mess. With a stack like that, it's a stretch to say you're "writing in Python" anymore.

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

#365

Post by tonyg »

hermitdev wrote: post #88
ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic t…

> One doesn't know the real type of a variable until runtime.

In the program

    def x(f):
        return f(3)
what is the "real type" of `f` at runtime; say, at the instant just before the call to `f`? How can you tell?

If your answer is that `f` has type "function-like", then that's a much weaker kind of a type than even type hints offer, let alone a real type system.

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

#366

Post by grumpyprole »

bayesian_horse wrote: post #352
grumpyprole wrote: post #345

Earlier quoted context omitted.

You might be more productive in Python versus anything else for the scale and complexity of the software you are involved in, but you cannot make sweeping generalisations like this. I also think you fail to understand that in many situations, static type systems actually improve productivity, especially at scale or for non-trivial domains. This is of course why Python is now trying to retrofit them. There's also the…

I "fail to understand" something you actually never did or experienced, right? I know that a lot of companies are maintaining large Python codebases, and the "lack of typechecking" might be one of the biggest pain points, but the total pain is a lot less. That was always my experience and most people who say differently haven't actually used Python that ... I know that Typescript helped me over Javascript. I don't ge…

> I "fail to understand" something you actually never did or experienced, right?

No, I have worked at a variety of large institutions that have millions of lines of Python. I work with it often. The use of Python is more about it being accessible for non-developers, which is why they also teach it in schools; and the need for a standard. It is the new "Visual Basic". Again, it is not more productive in all situations.

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

#367

Post by krageon »

bayesian_horse wrote: post #290
waitlist wrote: post #285

Earlier quoted context omitted.

I think data science is a perfect example in favor of types -- the code is often terrible because of the lack of typing. Pandas has notoriously poor developer ergonomics, and I recall painfully poring over type errors across the board -- lists, dataframes, numpy arrays, etc. are all iterables, so they can be interchanged in some contexts, but not in others. Had I had MyPy back when I was working in data science, I wo…

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding. No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect re…

> Pandas does is notoriously hard to fit into a compile-time type system

What, mutate data with known structure? What exactly do you imagine is hard about this, let alone notoriously so?

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

#368

Post by krageon »

bayesian_horse wrote: post #304
smohare wrote: post #300

Earlier quoted context omitted.

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately. The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re hav…

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries. I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the…

If you write more code that is untyped than typed, you are harming whoever comes after you. Untyped code is an absolute dragon even if it is properly documented (which it practically never is). Glorifying "productivity" and putting it above the greater good is essentially everything that's wrong with the world, at every level.

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

#369

Post by ReflectedImage »

kortex wrote: post #320
ReflectedImage wrote: post #220

Earlier quoted context omitted.

Typing in Python is generally a code smell. Typing encourages a large number of bad coding practices. If you can apply typing to a Python program then you are not taking advantage of the dynamic nature of the language to write simpler and shorter code. In Python world, unit tests cover what is normally handled by typing.

What. > Typing encourages a large number of bad coding practices. I'm sorry, what ? What exactly is the bad practice here? Not passing random dicts to my coworkers only to surprise them because the key was userid and not user_id? Or wasting time bugging an overworked dev to ask what their crazy 8 levels of dynamic indirection magic are doing, vs just being able to Cmd-B and step through the code path? > If you can ap…

The bad practice is treating a dynamically typed language as if it was a statically typed language.

There are shorter more concise ways to write your programs if you are not using static typing.

If you are not writing your Python programs in the Pythonic way then you are not really using Python correctly and you do not get most of the benefits of the language.

Unit tests exist for catching bugs in Python. Type hints are for documentation not for ensuring code correctness.

Yes, there are libraries that take advantage of type hints, through they could of used other annonations and it's valid to use type hints along with those libraries.

But as soon as you are attempting to prove your program doesn't have bugs via typing rather than unit testing. You have gone wrong.

Typed Python is far more bug prone, why? Because structuring your Python code to support typing means writing considerably more lines of code.

It not the type hints themselves but it's the way you will structure your program at a high level to support them.

The more lines of code the more bugs it has. Bugs are well known to be proportion to the number of lines of source code regardless of language used or whether the language is typed or not.

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

#370

Post by bmn__ »

gorgoiler wrote: post #162

I never liked how go makes you fix all your types before letting you run a program. Suppose I wanted to hack something up and run it, just as a new idea? Maybe change a library function that is called in 20 places, but I only want to test it in one call site. Nope! Go forces you to polish up your turd of an idea in all 20 call sites before you can see that your algorithm / model / refactoring is nonsense. If you back…

> Is there a “hey ho your types are all out of sync but let’s try and compile anyway” option?

"typed holes" in some programming languages

Post reply on HN