If you go from using dicts to objects, it's a pretty big API change. You ought to introduce it in parallel, so that people using the old path don't have to change their code.
On Fri, Feb 3, 2012 at 6:49 PM, Marcio O Silva <[email protected]>wrote: > Yes, that's exactly what I was thinking of doing. The class that was > generated would have properties for the fields specified in the schema, > complete with docstrings (if the field had a doc tag) and type validation. > > As for the incompatibility, I was thinking of extending DatumReader with a > SpecificDatumReader class that implemented this feature. If it's not a big > deal to change things, I could just do the work in the existing > DatumReader. > > On Fri, Feb 3, 2012 at 9:15 PM, Philip Zeyliger <[email protected]> > wrote: > > > Sounds great! It'd be an incompatible API (but that's ok, we can > > transition), but I like the way Python 2.6's namedtuple works. You call > > namedtuple(schema), and it produces a class object that you can use. > > Something like: > > > > klass = avro.make_record(schema_string, "recordname") > > > > could be quite handy. > > > > I'm not aware of anyone working on such a thing. > > > > -- Philip > > > > On Friday, February 3, 2012, Marcio O Silva wrote: > > > > > I was wondering if anyone was working on adding doc field support, or > > > creating an object for records in python. > > > If not, I was going to take a stab at adding schema support for doc > > fields > > > (and additional non-reserved json fields). > > > > > > Once that was done, I was thinking of implementing a specific record > > class > > > that provided property access in addition to the dict view. > > > > > > - Marcio Silva > > > > > >
