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
> On Fri, Feb 3, 2012 at 9:15 PM, Philip Zeyliger <[EMAIL PROTECTED]>
> > 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
> > >