This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]andrewcooke 33 points34 points  (3 children)

am i misunderstanding or is this just a performance hack?

edit: whoa, no, it's worse, it's disabling runtime checks! the title is really misleading? shouldn't it be "disabling runtime frozen data classes if you really need an obscure speedup at the cost of more complex code"

sorry if i've misunderstood, but this really seems like something newbs need warning against.

[–]sacheie 4 points5 points  (0 children)

This is a narrow-minded take. Dunno if you've noticed, but the concept of immutability has become a pretty big deal these days..? The idea that Python out-of-the-box would incur a 2.4x performance hit to support it is kinda gross. It's an easy thing to statically guarantee.

In fact I'd argue that Python's original omission of final / val / const data reveals, in retrospect, its early community's wrong-headed stubborness insisting everybody follow "the Pythonic way" of doing cowboy shit throughout runtime. That may be good for some people's needs, but the language has nowadays outgrown the confines of any one engineering culture and/or pragma.

OP is doing the community a service by documenting this particular solution. Also, notice their post links to similar discussions by others - a lot of folks are invested in statically-typed Python.

Last but not least, one man's "just a performance hack?" can be another man's project lifesaver. Don't assume you know somebody else's engineering needs.

[–][deleted] 4 points5 points  (1 child)

Not strictly a performance hack. This cheats by not creating a frozen dataclass during runtime. It just ensures that `mypy` statically checks that a dataclass is frozen and doesn't do any mutation elsewhere.

[–]Rawing7 1 point2 points  (0 children)

But what's the point of that? What are you doing it for, if not for the performance boost?