DBF records API

[Jon Clements]

On 01/06/12 23:13, Tim Chase wrote:
> On 06/01/12 15:05, Ethan Furman wrote:
>> MRAB wrote:
>>> 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.
>
> It seems to me that, since you provide both the indexing notation
> and the dotted notation, just ensure that the methods such as
>
>    dbf.scatter_fields
>
> *always* trump and refer to the method.  This allows for convenience

> of using the .field_name notation for the vast majority of cases,
> but ensures that it's still possible for the user (of your API) to
> use the indexing method to do things like
>
>    value = dbf["scatter_fields"]
>
> if they have a thusly-named field name and want its value.
>
> -tkc

I did think about *trumping* one way or the other, but both *ugh*.

Ethan:

I think offering both is over-complicating the design for no gain, and 
possible complications later. For instance, what if you introduce a 
method/property called "last" to get the last row of a table, it'll 
cause some head-scratching as someone will suddenly have to make sure 
your API changes didn't conflict with their column names (or if they've 
used yours as a base and introduce methods, doesn't interfere with their 
users of their version of the library...)

To most developers, I think blah["whatever"] is perfectly clear as 
looking up a value via key is mostly done that way.

I suppose you could use __getitem__ to grab certain fields in one go ( 
as per your example - from any iterable that isn't a basestring? - and 
users would probably enjoy not keep re-typing "record.xxx" and would 
save you having to invent another possibly conflicting name) such as:

print record['full_name', 'nick_name', 'pet_name']  # looks clean to me

In short I totally agree with MRAB here.

Just my 2p,

Jon.