I've found myself needing to generate documentation for the sheet importer. Since there's a large overlap between the sheet definition and the documentation of each field, it's nice to put everything in one place:
fields = (
FieldDoc('Column Header', 'column_key', parser, 'Column description', is_required=True),
)But this seems like scope creep for Tribune itself. Perhaps we could address this by making the Field type extensible. This could be accomplished several ways.
- Use make it a super class
Instead of using a namedtuple, turn Field into a class that can be inherited. As long as children classes have the necessary fields of header, key, parser, they can add as much as they want, including documentation metadata.
- Allow
Field to take an additional metadata field.
Keep Field as a namedtuple but add one more field to be used for anything the end-coder needs:
Field = namedtuple('Field', ['label', 'key', 'parser', 'metadata'])Ideally we'd make this metadata field optional and default it to None or something. That can be achieved several ways that I won't mention here.
The nice thing about option #2 is that in maintains the immutable nature of tuples and it's still very simple.
I've found myself needing to generate documentation for the sheet importer. Since there's a large overlap between the sheet definition and the documentation of each field, it's nice to put everything in one place:
But this seems like scope creep for Tribune itself. Perhaps we could address this by making the
Fieldtype extensible. This could be accomplished several ways.Instead of using a
namedtuple, turnFieldinto a class that can be inherited. As long as children classes have the necessary fields ofheader,key,parser, they can add as much as they want, including documentation metadata.Fieldto take an additionalmetadatafield.Keep
Fieldas anamedtuplebut add one more field to be used for anything the end-coder needs:Ideally we'd make this
metadatafield optional and default it toNoneor something. That can be achieved several ways that I won't mention here.The nice thing about option #2 is that in maintains the immutable nature of
tuplesand it's still very simple.