Records: A New Pythonic Data Type for Your Toolbox

namedtuple, classes and dictionaries are no longer the only options to represent a key/value mapping where all they keys are known upfront: Records may be a better alternative and they’re now available in Python via PyRecord.

This implementation is meant to be a highly improved version of namedtuple, but not yet a replacement. Features include:

  • Amazing inheritance support (inspired by tagged records in the Ada programming language).
  • Ability to set optional fields with default values.
  • Fully documented and with 100% of unit test coverage.
  • Runs on Python v2.7 to v3.x and PyPy v2.

Even though its latest version is a release candidate, the library is absolutely stable and has been in production systems for months.

Learn more about PyRecord

2 Comments Records: A New Pythonic Data Type for Your Toolbox

  1. Volodymyr Vitvitskyi

    Hi Gustavo, very neat library you developed.

    I like `collections.namedtuple` a lot for their immutability and `_replace` method =) Very often redefine `__new__` in them to make some fields optional, with default value.

    Regarding passing name of the record type explicitly, have you considered to make a sugar for that ?

    For instance, `“x”, “y”)` or `pyrecord.type.Point`.
    Also you can check `sh` library they make a wrapper for the module so you can do something like this

    from pyrecord import PointDef
    Point = PointDef('x', 'y')
    # or
    Point = pyrecord.Point('x', 'y')

    I tried this approach.

    class RecordNameProxy:
    def __getattr__(self, name):
    return lambda *args, **kwargs: Record.create_type(name, *args, **kwargs)
    type = RecordNameProxy()

  2. Gustavo

    Thanks, Volodymyr!

    Yes, indeed immutability is one thing PyRecord is missing. I have had needed it at least twice since I created the library. I’m hoping to work on it after the Christmas break.

    I too dislike having to repeat the name of the record type. I spent a long time researching and prototyping alternatives, but came to the conclusion that namedtuple’s approach (repeating the type name) was the best compromise.

    One of the options I considered was very similar to what you’re proposing, but I found two problems with it: It wouldn’t be correct to imply that PyRecord has a class named “Point” and it would not be good for static code analysis (inc. code completion in IDEs).

    I also considered exposing a second way to create record types, but then I remembered one point in the Zen of Python: “There should be one– and preferably only one –obvious way to do it”.

Comments are closed.