Hacker News Reader

Comment by PaulHoule | Hacker News Reader

In practice the hashtable implementation in Python is so fast, particularly for cases like

  {"x": 51.2, "y": -74.1 }

that you don't gain a lot from namedtuples most of the time. I quit benching namedtuples for applications like that a long time ago.

View on HN

The main problem of dicts is that they're really heavy memory-wise, even with key-shared dicts and stuff.

Your dict is 232 bytes, the equivalent tuple is 56.

How much does automatic interning of string literals help out here?

It doesn't. That's the size assuming interning of string literals.

Glurk! Thanks.

sys.getsizeof is not recursive so that's just the size of the collection itself, excluding the stuff it references (so both keys and values are additional, here the strings are literal so they're interned and part of the program constants).

I thought I'd add to this (because I was surprised) that the equivalent namedtuple is also 56 bytes (I expected it to be larger) and the equivalent dataclass is a mere 48 bytes. (although there's overhead for defining a namedtuple or a dataclass, on the order of a constant 1kb).

Although there seems to be some kind of trickery happening there, because if I make the class accept 3 floats instead of two, neither the class nor the instance get larger.

> and the equivalent dataclass is a mere 48 bytes

> Although there seems to be some kind of trickery happening there, because if I make the class accept 3 floats instead of two, neither the class nor the instance get larger.

The dataclass stores stuff in a normal instance __dict__ and sys.getsize is not recursive.

namedtuples are variable-size instances, they store the attributes “inline”.

a.x is far easier to both read and write than a[”x”] (67% is operator syntax compared to 33% in a.x).

this and () => {} syntax have always been moderate to strong wins in my book for js when creative-coding

Not to mention that the first case gets assistance from autocomplete in an IDE or ipython session. That speeds up typing long, descriptive names so much.

Immutability is nice though.

Also it's nice for bad references to trigger AttributeError which is almost always a design error, whereas KeyError is not always so.

I haven't tried it but type hints are probably smart enough to find errors like this statically with namedtuple, but probably not so with a dict.

I think you need to use typing.NamedTuple to get typing support. On the other hand, you can use TypedDict [1] to get type hints on dictionaries.

1: https://www.python.org/dev/peps/pep-0589/

In cases where you don't care about immutability, I'd think of it as a better version of TypedDict (though TypedDict still has its place). It makes my IDE more helpful, makes my code more self-documenting, and allows mypy to tell me when I'm being dumb.

That's only because Python is so slow in general and everything else is implemented in terms of hashtable lookups too.

You could define __slots__ on the namedtuple that would not use a hashtable for lookups.

Reply on news.ycombinator.com