5 ms·

Is there not a single namedtuple in the entire Google codebase? That's strange :o

• brianwawok 10y ago
  Are namedtuples that popular? They always felt awkward to me. If some temp variable with multiple values inside a loop, I either use normal tuple or a dict. If passing data around a dict or a real class. I never got the huge win from namedtuple?
  • jonasvp 10y ago
    Attrs (https://attrs.readthedocs.io/ https://attrs.readthedocs.io/) replaced namedtuple for us (and many others). It's slightly more verbose but allows all class goodness such as methods, attribute validation, etc.
    • justinsaccount 10y ago
      Doesn't work for everything, but you can subclass a namedtuple: from collections import namedtuple class Foo(namedtuple("Foo", "a b c")): @property def sum(self): return self.a + self.b + self.c f = Foo(1,2,3) print f.sum
      • brianwawok 10y ago
        That doesn't look super awesome to me. I.e. classes or attrs both seem better.
        • deleted 10y ago
          [deleted]
    • foxylad 10y ago
      Aaaaaarrrrrgggggh! I've had that particular itch for every one of my ten years with python, and at last I get to scratch it! Thanks so much for bringing it up.
  • beagle3 10y ago
    namedtuples are tuples, meaning they are stored efficiently, and are constant (thus can also be used as dictionary keys). Unlike regular tuples, they can be accessed like a class/dictionary for readability, but requiring much less allocations (compared to dict/class), so much faster. Also, as they are tuples, you have well defined methods (printing, comparison, hash value, ) you'd have to implement yourself for dict/class. If you like writing in functional style, namedtuples are much more natural than dict or classes, and more efficient to boot.
  • cscharenberg 10y ago
    We use them extensively in our API client code to pass back immutable, well-defined data structures. Dictionaries and classes are mutable and then each layer of code tends to sloppily change them however is convenient, meaning the underlying data can end up being represented differently in different code flows. Namedtuples are a way to preserve the data unless the consuming code _really_ wants to change it, which is sometimes legitimate. I'm not totally sold, as in some cases dictionaries or classes would add nice value. But namedtuples have a rigidity that makes you think twice before tampering with retrieved data.
  • bbtony 10y ago
    In every introductory python course tuples are presented as just immutable lists. However a "more accurate" way of describing tuples is if you think of them as records with no field names. When you see tuples as records then the fact that are inmutable make sense, since the order and quantity of the items matters (it remains constant). Records usually have field names and here is where namedtuples comes in handy. Also helps to clarify what the tuples wear (see https://youtu.be/wf-BqAjZb8M?t=44m45s https://youtu.be/wf-BqAjZb8M?t=44m45s), just 2 minutes clip. If you are thinking why don't define a class, I will tell you a couple of reasons: 1) You know before hand that the number of items won't be modified and the order matters since you are handling records. So it is a simple way of accomplishing that constraint. 2) Because they extend tuple they are inmutable too and therefore they don't store attributes per instance __dict__, field names are stored in the class so if you have tons of instances you save a lot of space. Why creating a class if you just probably need a read-only interaction? But what about if you need some method? Then you can extend your namedtuple class and add the functionality you want. If for example you want to control the values of the fields when you are creating the namedtuple you can create your own namedtuple by overriding __new__. At that point it is worth it to take a look at https://pypi.python.org/pypi/recordclass https://pypi.python.org/pypi/recordclass.
• trotterdylan 10y ago
  Heh, I came across the namedtuple exec thing the other day when I was trying to get the collections module working :\ namedtuple will have to be implemented differently. I think it can be accomplished by defining the class with type()? Maybe with a metaclass...
  • xapata 10y ago
    You won't get exact compatibility, but a metaclass implementation would give almost all the features. I can't remember what exactly you give up, but I did that once and I lost some introspection friendliness.
    • xapata 10y ago
      Nevermind, all you need is type(). Metaclass unnecessary.
  • pdonis 10y ago
    > I think it can be accomplished by defining the class with type()? I've done it using more or less that method. The code is in the "coll" sub-package of my plib.stdlib project; the Python 2 version is here on bitbucket: https://bitbucket.org/pdonis/plib-stdlib/src https://bitbucket.org/pdonis/plib-stdlib/src
• bru 10y ago
  (1) A grep can identify all the occurrences; a sed might even fix them. (translated to Google internal tools obviously) (2) Apparently setting a __dict__ key works; they could be implemented like that.
• ubernostrum 10y ago
  There are some defined in built-in modules. Even in Python 2.7, where sys.version_info is a namedtuple.
  • cben 10y ago
    Yeah, one of the motivations for adding namedtuple to stdlib was a drop-in compatible upgrade of existing interfaces returning tuples. Notable atrocities included `time.localtime()` returning a 9-tuple, and `os.stat()` returning a 10-tuple...