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

201–210 of 264 posts

Re: Python's “disappointing” superpowers

#201

Post by pdonis »

phailhaus wrote: post #196
pdonis wrote: post #187

Earlier quoted context omitted.

> There is no difference between `object["hello"]` and `object.hello`. Ah, ok. Technically I suppose one could unify these in Python; attribute accesses on objects are really dict lookups under the hood, and one could implement a list as a dict whose keys were restricted to be integers. But yes, Python chose not to go that route. > I meant that you can't create an equivalent class that typechecks the same way. Well,…

> You mean you lose some functionality with third party type checking tools No, I mean that Python cannot express this relationship with type annotations. That's why plugins are necessary, because the language doesn't support it. I think the same is true for `TypedDict`, which is why the community had to wait for official support before it could be used. These fundamental limitations of the language prevent the commu…

> Python cannot express this relationship with type annotations.

What relationship? That two classes which have no ancestor classes in common happen to be duck type compatible? Yes, Python type annotations can't express that, because there is no type relationship to express.

The way to avoid this problem in Python is to make sure duck type compatible classes have an ancestor class in common. That was a main point of the collections.abc module when it was introduced, to provide actual classes that expressed the duck types that were built into Python (being a subclass of MutableMapping, for example, expresses the fact that a class is duck type compatible with the built-in dict class).

As for "dataclass", it's not a class, it's a function. But the dataclass module provides the "is_dataclass" function that you can call on any class to check whether it's a dataclass. As far as I know, this will detect both your "dataclass_alias" and "dataclass_wrapper" cases. So this function could be used by any tool that wants to check for dataclasses.

Re: Python's “disappointing” superpowers

#202

Post by pdonis »

phailhaus wrote: post #196
pdonis wrote: post #187

Earlier quoted context omitted.

> There is no difference between `object["hello"]` and `object.hello`. Ah, ok. Technically I suppose one could unify these in Python; attribute accesses on objects are really dict lookups under the hood, and one could implement a list as a dict whose keys were restricted to be integers. But yes, Python chose not to go that route. > I meant that you can't create an equivalent class that typechecks the same way. Well,…

> You mean you lose some functionality with third party type checking tools No, I mean that Python cannot express this relationship with type annotations. That's why plugins are necessary, because the language doesn't support it. I think the same is true for `TypedDict`, which is why the community had to wait for official support before it could be used. These fundamental limitations of the language prevent the commu…

> All of this to say: it could have been a contender! It could have been like TypeScript!!

No, it's to say: "I think Python should have done things the way TypeScript does!" But Python is not TypeScript. It's a different language with a different design philosophy. Expecting to use it exactly the way you would use TypeScript is of course not going to work out well, just as expecting to use TypeScript exactly the way you would use Python is not going to work out well.

Re: Python's “disappointing” superpowers

#203

Post by pdonis »

phailhaus wrote: post #196
pdonis wrote: post #187

Earlier quoted context omitted.

> There is no difference between `object["hello"]` and `object.hello`. Ah, ok. Technically I suppose one could unify these in Python; attribute accesses on objects are really dict lookups under the hood, and one could implement a list as a dict whose keys were restricted to be integers. But yes, Python chose not to go that route. > I meant that you can't create an equivalent class that typechecks the same way. Well,…

> You mean you lose some functionality with third party type checking tools No, I mean that Python cannot express this relationship with type annotations. That's why plugins are necessary, because the language doesn't support it. I think the same is true for `TypedDict`, which is why the community had to wait for official support before it could be used. These fundamental limitations of the language prevent the commu…

> I think the same is true for `TypedDict`

The typing module is pure Python, so the code for TypedDict in that module could have been implemented by any Python user. The official support is of course nicer, but is not required to extend the functionality of the typing module.

Re: Python's “disappointing” superpowers

#204

Post by rendaw »

taeric wrote: post #172
cageface wrote: post #165

Earlier quoted context omitted.

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

What did I make an equivalence between? Large codebases are hard, period. That is all I am saying. Having worked on 100k LOC systems in static and in dynamic, I will not claim either has a benefit. That is just hard. Static analysis is, of course, good. If that is static typing or otherwise. So is running the code making sure it does what you want when running. What is not a huge help, is a byzantine type hierarchy t…

The equivalence you're making is that dynamically-typed large code bases are just as difficult to get into as statically-typed large code bases.

Re: Python's “disappointing” superpowers

#205

Post by cageface »

taeric wrote: post #194
random314 wrote: post #193

Earlier quoted context omitted.

Dude, you have already made up your mind, so I am not going to do any homework for you that you yourself aren't performing. You are not my boss, or anyone's boss here

Amusingly, you don't know my actual stance. Which is probably closer to pro static types than to dynamic. My criticisms in this thread is that the static type brigade does not hinge on evidence. It is typically hollow claims and getting angry at dynamic languages for being obviously bad for lack of helping.

Hard evidence is hard to obtain for something as varied and unrigorous as software.

After 25 years of working on all kinds of codebases I’ll take even badly engineered statically typed code over dynamic any day of the week including Sunday.

Re: Python's “disappointing” superpowers

#206

Post by super_flanker »

random314 wrote: post #188
taeric wrote: post #185

Earlier quoted context omitted.

Then do said survey? Find empirical evidence and share it. My experience, sadly, is the louder a dev on the team is about either dynamic or static typing, the more likely that dev's code is something nobody else in the team wants to work with.

Here is one sample point for your survey. Static is better than dynamic for large projects, in my experience.

+1

Re: Python's “disappointing” superpowers

#207

Post by albertopv »

deshpand wrote: post #195
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…

A ~100k LOC project in a statically typed system with type hierarchies, interfaces, contracts and boiler plate will boil down to ~10k LOC in a dynamically typed language like Python. A 10k LOC project will be more readable than a 100k LOC project. Source: I have spent years coding in C++/Java, then Python. I have migrated Java projects into Python

You probably were replacing LoC with libraries or syntactic sugar, you can do the same with java. As a senior I can write same functionality than juniors with half LoC. In my experience Python is totally unusable when dealing with poorly documented 3rd party libs.

Re: Python's “disappointing” superpowers

#208

Post by fithisux »

My personal experience is that static typing not only eliminates a huge number of unit tests but increases documentation expression in combinationn with good names.

Dynamic typing is excellent for experimentation though.

Python hits the sweet spot.

But I can definitely recommend Groovy as an excellent alternative having all the strengths of the Java ecosystem.

Scala and Kotlin are also quickly catching up.

Re: Python's “disappointing” superpowers

#209

Post by super_flanker »

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]

You have clearly made up your mind and no matter what someone says you won't change it. Good luck learning new skills.

Re: Python's “disappointing” superpowers

#210

Post by albertopv »

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…

Dynamic languages large code based are, in my 14yo experience, much much harder. Today no one a serious project with javascritpt, AFAIK everybody use typescript. Why?
Post reply on HN