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

541–550 of 597 posts

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

#541

Post by bayesian_horse »

int_19h wrote: post #536
qsort wrote: post #378

Earlier quoted context omitted.

Not hard per se, but extremely unergonomic. A pandas dataframe types to something like Iterable[SomeKindOfProductType[int, str, str, ... (78 other columns)]]. The formal type of a dataframe in the middle of a transformation is... not very useful to know.

It's not very useful to type , but that's why we have type inference. It's certainly very useful to know , even if that knowledge is indirect via the type of the resulting dataframe after all the transforms.

From dabbling in F# I have a feeling such "information" would be somewhat more annoying than useful.

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

#542

Post by bayesian_horse »

int_19h wrote: post #534
bayesian_horse wrote: post #290

Earlier quoted context omitted.

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…

> What Pandas does is notoriously hard to fit into a compile-time type system. Sounds a lot like F# type providers to me. https://thesharperdev.com/introduction-to-fsharp-type-provid...

As I said, it is hard.

And good luck teaching beginning scientists F#.

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

#543

Post by bayesian_horse »

arinlen wrote: post #391
bayesian_horse wrote: post #349

Earlier quoted context omitted.

I didn't say "with compile-time languages" but "with compile-time type systems". And many similar tools in a statically typed language will necessarily create a way to have one static type that doesn't care what the data inside actually looks like. This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor. Worse,…

> This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor. That doesn't sound like a Python problem. Instead, it sounds like the natural consequence of numpy being designed in a way where their data types aren't organized into subtypes, and leave that as runtime properties. This is a natural reflection of numpy'…

Of course it's not a Python problem, all similar tools have the same "problem" that they can't easily fit that stuff into their type systems, so they invent some way to not care about it.

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

#544

Post by bayesian_horse »

int_19h wrote: post #537
HelloNurse wrote: post #353

Earlier quoted context omitted.

It isn't a matter of "compile time": explicit type declarations and definitions can often be formally sound but practically worthless. Significant types in ETL-style applications typically come from outside (e.g. a certain CSV column in the input file contains a date in YYYYMMDD format, or maybe YYYYDDMM, figure it out, and don't forget time zones or your accounting will go wrong). Then types are mostly complex but o…

The source code shouldn't need to say anything about the type of the resulting matrix explicitly, perhaps. But why shouldn't the type system keep track of shapes and deduce the accurate type for the result of said multiplication?

Because the shape can be dynamic, for example.

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

#545

Post by bayesian_horse »

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…

Scaling a code base doesn't start or end with type checking. Some of the answers to what you are implying is: Use interfaces when using OOP. Consider dependency injection or other Inversion of Control patterns. Maybe don't use OOP as much...

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

#546

Post by bayesian_horse »

gilbetron wrote: post #451
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.

Python has a tremendous amount of momentum because it has become so popular outside of the traditional software development world, but other languages are picking away at it, even given that momentum. And while I am in a bubble, like everyone else, in my bubble, and those I talk to in my bubble, all see large a shift away from Python. Adding stronger typing, like type hints, could reverse that, of course. The reason…

That "shift" away from Python wouldn't be seen in any particular data, right?

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

#547

Post by bayesian_horse »

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'd say all metrics point to the popularity of Python increasing, while there is no data indicating that people are fleeing Python en masse. Or at all, actually.

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

#548

Post by bayesian_horse »

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 did not say type hints damaged productivity. There is no evidence to point either way, actually.

Gradual typing is based on effort. Most people won't spend the effort. And they don't need to, most of the time, either.

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

#549

Post by oriolid »

CraigJPerry wrote: post #517
oriolid wrote: post #484

Earlier quoted context omitted.

On a quick search, for example https://link.springer.com/article/10.1007/s10664-013-9289-1 . "This paper describes an experiment that tests whether static type systems improve the maintainability of software systems, in terms of understanding undocumented code, fixing type errors, and fixing semantic errors. The results show rigorous empirical evidence that static types are indeed beneficial to these activities, exce…

Cool - this paper has 3 conclusions: - Static type systems are an effective form of documentation – Static type systems reduce the effort to fix type errors – Static type systems may not be helpful in preventing semantic errors It would have been awesome to have evidence for #3 but even just #1 & #2 could be useful, albeit to a much lesser extent. Could we quantify by how much? It’d be important to quantify because i…

For the second paper, looks like the test task is quite small and the language used requires more work from developer than a modern static type system with type inference and generics. Still the difference between static and dynamic typed variants is rather small. I wonder if the situation would change if the project took weeks or months instead of hours, but that would be an expensive experiment. Also, it would be interesting to see if type inference and generics would increase productivity but in the real world we are stuck with Java and Go anyway.

Other take home message is that the famous 10x programmer was found in both groups. The one with dynamic language was faster, just as the argument for dynamic typing goes.

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

#550

Post by kortex »

tonyg wrote: post #364
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.

It's more so "this is my toolchain I use for my own ergonomics, and what you can achieve with the right kit".

Who cares if I'm "writing in python" at all? I'm solving problems. Honestly a good IDE (pycharm or vscode) will give you 80% of the ergonomics.

Post reply on HN