Re:Redesigning Python's named tuples
by bkul on Friday September 01, 2017 @01:01AM
(#15146229)
Seems to me that classes generally replace structs in such languages. I know they're not the same thing, but classes have the features of structs (and much more) at the cost of performance.
[ Parent
| on HN ]
A lot of people (my whole company, for sure) are using namedtuples essentially just as immutable structs. This is a case where classes aren't sufficing. To be fair, it's at least a little bit the functional-programming, immutability bandwagon, but either way it's helping maintain large python apps with many devs.
Python36 gradual typing also helps here though, and am definitely interested to see if that changes the game a bit
Re:Redesigning Python's named tuples
by smitherfield on Friday September 01, 2017 @01:11AM
(#15146263)
> classes have the features of structs (and much more) at the cost of performance.
Not true; C++ classes have zero performance overhead over C/C++ structs (because they're just another word for the same thing).
Of course Python classes have a lot of costly features that C++ classes don't have, but the notion of a "class" (with methods, constructors etc) is not one of them.
Re:Redesigning Python's named tuples
by kronos29296 on Friday September 01, 2017 @01:41AM
(#15146398)
And also makes them look more complicated with more syntax. C++ has all those features that I will never know without adding performance. But people don't use Python for performance but ease of use.
In C++ ease of use is given up for the sake of performance. In python it is the other way.
Don't C++ classes (and therefore structs) have a hidden vtable?
vtable is always "hidden". It's only there when there is at least one virtual member defined. Sole difference between class and struct in C++ is default visibility.
class A {
int a; // private
}
struct A {
int a; // public
}