login
Holden Web
What you'll need to know tomorrow

Comments on Why Tuples?, page 2 of 3

@toddr2178: Your point being? @claudio: Good poin...

Steve · 2013-04-28T15:27:56.578000

@toddr2178: Your point being?

@claudio: Good point.

@Samus_: You made that up, didn't you? Tuples are used as dict keys all the time.

We use TCP/IP five tuples as keys in a dictionary ...

Anonymous · 2013-04-28T16:33:12.656000

We use TCP/IP five tuples as keys in a dictionary of connection specific data.

I wish Python had an equivalent to Javascript'...

Laurence Rowe · 2013-04-28T22:00:54.430000

I wish Python had an equivalent to Javascript's Object.freeze so that tuples wouldn't see so much abuse as frozen lists.

PEP-351, "The freeze protocol" was rejected, but that dealt with creating a hashable copy rather than simply disabling further mutation of an existing object.

@toddrme2178, @Steve: One main reason for using na...

Johan Nestaas · 2013-04-29T00:01:15.399000

@toddrme2178, @Steve:
One main reason for using namedtuples over dicts is for performance and to reduce memory usage, as well as being immutable.

dynamic dicts can really hurt performance if you're instantiating a lot at a time, and it's wasteful if you can do the same exact thing with a namedtuple, especially when immutability makes sense for the object.

Consider a namedtuple that represents a specific sequence of bytes for a file. You might want to have filepath, memory_address, sequence. You aren't editing the files, so you just want to scrape through a filesystem and figure out which files have that sequence, therefore you don't want to change the values ever. If you might find 20 millions instances of that sequence, you can save a lot of RAM by using a named tuple, and it represents an object which can and should be immutable.

I've seen this sort of thing in practice, namedtuples make the most sense, and it can really improve performance if you're doing this at a large scale.

@Johann: Yes, I agree, the immutability and speed ...

Steve · 2013-04-29T00:09:07.583000

@Johann: Yes, I agree, the immutability and speed are important reasons for choosing a named tuple. The dict is far too general a data structure to be efficient in applications like those you mention.

# It is possible to subclass a namedtuple: from c...

Anonymous · 2013-04-29T05:56:36.742000

# It is possible to subclass a namedtuple:

from collections import namedtuple
fields = ('states', 'symbols', 'transition', 'initial', 'accepting_states')
NFA = namedtuple('NFA', fields)
_nfa = NFA(*fields)
_nfa._fields, _nfa._asdict()

class NFAWithMethods(NFA):
def print_symbols(self):
print(self.symbols)

_nfa = NFAWithMethods(*fields)
_nfa.print_symbols()

Yes, one could, But to do so would be a perversion...

Steve · 2013-04-29T06:17:05.363000

Yes, one could, But to do so would be a perversion building, as it does, one unsatisfactory layer on top of another.

Fortunately Raymond knows where to stop, and so we have namedtuple instead. I was wondering whether a slimmed-down version (something like the bunch class) might be useful, not considering adding more cruft!

This does neatly demonstrate the Python geek tendency to focus on ever more peripheral questions. Let's try and resist that, shall we?

mydict[('some', 'random', 'stu...

Samus_ · 2013-04-29T07:02:35.055000

mydict[('some', 'random', 'stuff')] = 'really?'

no seriously, I haven't seen this anywhere and it's a terrible idea imho.

I unpack from struct.unpack into a namedtuple. A t...

Anonymous · 2013-04-29T07:18:30.186000

I unpack from struct.unpack into a namedtuple. A tuple subclass with property accessors is perfect for my needs. Don't mess with namedtuple...

There's the built-in namespace object in version 3.3, i.e. types.SimpleNamespace. In 3.3 it's used by sys.implementation and time.get_clock_info(). Basically, it's like a heap type defined with __slots__ = ('__dict__',), so no weak references.

Steve · 2013-04-29T07:57:54.309000

This comment has been removed by the author.

Older comments · Page 2 of 3 · Newer comments

Back to post