Should represent Table's fields declaration and rows instances as a class?

Currently we use two data types to represent something that could be represented in one class. The first is the fields parameter received by import_from_* (which are passed to utils.create_table), like:

UWSGI_FIELDS = OrderedDict([('pid', rows.fields.IntegerField),
                            ('ip', rows.fields.UnicodeField),
                            ('datetime', rows.fields.DatetimeField),
                            ('http_verb', rows.fields.UnicodeField),
                            ('http_path', rows.fields.UnicodeField),
                            ('generation_time', rows.fields.FloatField),
                            ('http_version', rows.fields.FloatField),
                            ('http_status', rows.fields.IntegerField)])

Second is the Table.Row (created in Table.__init__), which is a named tuple containing row data.

We could use an approach similar to ORMs and use a class to define the fields, like Django does. We could start with something like this:

class UwsgiLog(rows.Row):
    pid = rows.fields.IntegerField()
    ip = rows.fields.UnicodeField()
    datetime = rows.fields.DatetimeField()
    http_verb = rows.fields.UnicodeField()
    http_path = rows.fields.UnicodeField()
    generation_time = rows.fields.FloatField()
    http_version = rows.fields.FloatField()
    http_status = rows.fields.IntegerField()    

And the Table rows (returned when we iterate over it) will be instances of UwsgiLog.

Pros:

• This syntax is more flexible since we can create utility methods inside the class
• More declarative

Cons:

• We may not have access to the field order in this case (which is very important)
• namedtuple is probably faster than any other customized class
• We'll need to add more complexity to the code

Note: check if we can integrate this feature with scrapy so it'll easier to parse data using rows in a scrapy project.