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

Python's “disappointing” superpowers

lukeplant.me.uk

Post reply on HN
Print view View original

161–170 of 264 posts

Re: Python's “disappointing” superpowers

#161

Post by codexb »

wheelerof4te wrote: post #22

Either embrace dynamic typing and provide good error guards...or try to use type hints and still make good error guards. We had an entire history of Python 2 without type hints. Why use them now?

Spoken like someone who's never had to step into a 2 million line python library and try to decipher or debug it.

Also, we've been using non-standard type hints for nearly all of python 2, they were just non-uniformly specified in docstrings and weren't easily referenced or introspected for tooling and IDE's to work with them.

Re: Python's “disappointing” superpowers

#162

Post by codexb »

thereisnospork wrote: post #48

While this might be about my most unpopular opinion, it feels like it is time to start putting together a Python 4.0. I don't particularly have skin in the game but there is(?) enough meat on the bone around things like improving the GIL status quo, JIT compiling, static typing, and presumably etc. to be worth a breaking change.

The GIL is already set to be optionally removable via a compile-time flag in an upcoming release. That's about as meaty a change as you can get, and it's still not going to require a 4.x release.

Re: Python's “disappointing” superpowers

#163

Post by ReflectedImage »

phailhaus wrote: post #155
ReflectedImage wrote: post #152

Earlier quoted context omitted.

Here's a citation if it makes you happy: https://games.greggman.com/game/dynamic-typing-static-typing... 2% of bugs can be caught via static typing. For your very simple example, your IDE can do that!

Here is a study that show Python is more bug-prone and that TypeScript is far more reliable: https://danluu.com/empirical-pl/ That source shows why language studies are so difficult, and why it is hard to draw conclusions. For example, your study doesn't count KeyErrors or NoneType exceptions as type errors, but those count as well. There are other considerations: you're only looking at released projects which might…

[flagged]

Re: Python's “disappointing” superpowers

#164

Post by phailhaus »

codexb wrote: post #159
phailhaus wrote: post #62

Earlier quoted context omitted.

> its datamodel is overally less of a hot mess compared to Javascript for example. I don't understand this, what do you mean? TypeScript is such a success partly because everything is an object in Javascript. There's no need to distinguish between classes and "dicts", as you have to with Python. Another example: Python functions have args and kwargs, which make typing significantly more complex (as the article points…

> Python functions have args and kwargs, which make typing significantly more complex Not really. It's only complex when they're used with poor design decisions. There are plenty of languages that allow you to do things that aren't a good idea. Python is no exception. Type hinting just makes those shortcomings more readily apparent. > Callable doesn't even support kwargs PEP 544 and Protocols have existed for 5 years…

I'm talking more about really simple patterns that Python's type system just can't support. Take kwargs. They've existed forever. A really common and not-stupid pattern is to write a subclass such that you only specify some arguments you care about, and then take *kwargs to pass on to the super constructor. Can't type this. You have to exhaustively enumerate those kwargs and pass them in manually, or else you lose type hinting for your subclass.

Re: Python's “disappointing” superpowers

#165

Post by cageface »

taeric wrote: post #158
spoils19 wrote: post #149

I used to be a huge dynamic languages fan, with python being my favorite language over the majority of my career. Then I worked on a large python project of ~100k LOC with a team of ten. That's when I realized that writing code faster isn't the problem. Reading it is, making changes to code someone else wrote is, and refactoring across dozens of modules is a problem. Static languages help a lot with all three. I stil…

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping. I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to…

This is a false equivalence.

You need all the help you can get maintaining large codebases and static typing is a huge help.

Re: Python's “disappointing” superpowers

#166

Post by lostmsu »

ReflectedImage wrote: post #119
lostmsu wrote: post #26

Earlier quoted context omitted.

> Python remains a fantastic prototyping and scripting language I think it sucks for prototyping too if your prototype is constantly evolving. I have a WIP with about 100 files in it that I've been aggressively evolving over the past year, and I already want to rewrite everything in something statically typed, because any kind of change became pain in the ass. Too bad the project requires Python-first libraries.

Large Python projects are done with microservices typically.

1. I would not call 100 short files 1/3 of which are simple tests "large". I've handled 10 times larger C# projects without any hiccups.

2. This is a deep learning research project. Files are layers, pure functions, and model builders. Can't really turn it into microservices.

Re: Python's “disappointing” superpowers

#167

Post by codexb »

lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

Rust and Typescript are some of the most well-loved languages, and the typing semantics of python are almost identical.

Have you used VSCode? or PyCharm? Their typehinting support is pretty great. At least as good as anything for typescript.

Re: Python's “disappointing” superpowers

#168

Post by phailhaus »

ReflectedImage wrote: post #163
phailhaus wrote: post #155

Earlier quoted context omitted.

Here is a study that show Python is more bug-prone and that TypeScript is far more reliable: https://danluu.com/empirical-pl/ That source shows why language studies are so difficult, and why it is hard to draw conclusions. For example, your study doesn't count KeyErrors or NoneType exceptions as type errors, but those count as well. There are other considerations: you're only looking at released projects which might…

[flagged]

That is the most brazenly false statement I've ever heard. "Python is superior due to dynamic typing, and also all types in Python can be statically inferred!" Wow, you should let them know that type hints was a total waste of time because you could already infer them!

I think it's clear you have a very weak understanding of this topic, and you have no interest in having a civil conversation. Good night!

Re: Python's “disappointing” superpowers

#169

Post by codexb »

phailhaus wrote: post #164
codexb wrote: post #159

Earlier quoted context omitted.

> Python functions have args and kwargs, which make typing significantly more complex Not really. It's only complex when they're used with poor design decisions. There are plenty of languages that allow you to do things that aren't a good idea. Python is no exception. Type hinting just makes those shortcomings more readily apparent. > Callable doesn't even support kwargs PEP 544 and Protocols have existed for 5 years…

I'm talking more about really simple patterns that Python's type system just can't support. Take kwargs. They've existed forever. A really common and not-stupid pattern is to write a subclass such that you only specify some arguments you care about, and then take *kwargs to pass on to the super constructor. Can't type this. You have to exhaustively enumerate those kwargs and pass them in manually, or else you lose ty…

Yes, that exact scenario is supported with TypedDict.

And while that is a simple pattern, it's not a good pattern, and quickly becomes unmaintainable in a program of any size. Using *kwargs because of Too-many-arguments and so you can violate the Liskov substitution principle isn't good programming. Just because it can be done doesn't mean we should start bastardizing typing to make it easier.

Re: Python's “disappointing” superpowers

#170

Post by lostmsu »

ReflectedImage wrote: post #145
mountainriver wrote: post #138

Earlier quoted context omitted.

Static typing is not just about code performance, it’s absolutely about correctness as well. I would really love to see that study as it flys in the face of all my experience

https://games.greggman.com/game/dynamic-typing-static-typing...

> has on average 2.5x the number of bugs

This claim is not supported by the linked article.

In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language.

To give a concrete example, I went out to GitHub, got into top Python repository (TensorFlow), and searched for a first closed pull request which explicitly mentioned ValueError and did not mention either of the above. It turned out to be this one: https://github.com/tensorflow/tensorflow/pull/47017 This issue is an obvious type error: in statically-typed languages the value of float can not be nil.

You could probably repeat that experiment with other closed pull requests, but I can bet you you will find that the rate will be closer to 50% if not 90%.

Post reply on HN