DBF records API

[Ethan Furman]

MRAB wrote:
> On 01/06/2012 18:50, Ethan Furman wrote:
>> I'm getting towards an actual non-beta release, which means even more
>> tests, polishings, cleaning up of various things, and actual
>> documentation.  :)
>>
>> However, I am wondering about my current record API:
>>
>> Currently, one does things like:
>>
>>     record.scatter_fields()
>>
>> or
>>
>>     record.has_been_deleted
>>
>> or
>>
>>     record.record_number
>>
>> The reason those method names are so long is that field names are
>> limited to 10 characters, and long method names means no possibility of
>> name clashes.
>>
>> Unfortunately, Version 7 tables can have much longer field names.
>>
>> So, do I not ever support version 7, do I not worry about it until I get
>> there (which could easily be a long time from now), or do I move all the
>> methods out of the record class and make them module level functions
>> instead?  That would like:
>>
>>     dbf.scatter_fields(record)
>>
>>     dbf.has_been_deleted(record)
>>
>>     dbf.record_number(record)
>>
>> although probably with shorter names.
>>
>> Thoughts?
>>
> I'd probably think of a record as being more like a dict (or an 
> OrderedDict)
> with the fields accessed by key:
> 
>     record["name"]
> 
> but:
> 
>     record.deleted

Record fields are accessible both by key and by attribute -- by key 
primarily for those cases when the field name is in a variable:

     for field in ('full_name','nick_name','pet_name'):
         print record[field]

and since dbf record names cannot start with _ and are at most 10 
characters long I've used longer than that method names... but if I want 
to support dbf version 7 that won't work.

I would like to, not sure I will (it's not a need for me at work), but 
prudence suggests I make the easy preparations now.

~Ethan~