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.
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, `pyrecord.new.Point(“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')
Point = pyrecord.Point('x', 'y')
I tried this approach.
def __getattr__(self, name):
return lambda *args, **kwargs: Record.create_type(name, *args, **kwargs)
type = RecordNameProxy()
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”.