BIND 10 #2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor

BIND 10 Development do-not-reply at isc.org
Thu Jun 6 00:40:00 UTC 2013


#2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  pselkirk
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130611
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by pselkirk):

 Replying to [comment:8 vorner]:

 > '''Potential problems'''
 >
 > Is it OK to delete the accessor before the client list it comes from? If
 it should not happen, we should ensure it with the `base_obj` trick like
 in the case of the iterator.

 It's okay to delete the accessor before the client list. It's not okay to
 delete the client list before the accessor, which appears to be the intent
 of the `base_obj` trick. So I added it to `createZoneTableAccessorObject`.

 > In `ZoneTableIterator_next` (unless you agree to delete it), the catch-
 all omits setting the error string.

 Deleted it.

 > You should be returning by py_ReturnTrue and pyReturFalse (not sure
 about the exact spelling) here, not by integer. Python has booleans.
 > {{{#!c++
 > PyObject*
 > ZoneTableIterator_isLast(PyObject* po_self, PyObject*) {
 >     s_ZoneTableIterator* self =
 static_cast<s_ZoneTableIterator*>(po_self);
 >     try {
 >         return (Py_BuildValue("i", self->cppobj->isLast()));
 >     } catch (...) {
 >         return (NULL);
 >     }
 > }}}

 Deleted that as well.

 > There should be a wrapper for isc::dns::Name, returning string is wrong.

 Okay, found `isc::dns::python::createNameObject()`

 > '''Style'''
 >
 > Things like this look awkward:
 > {{{#!c++
 > accessor.reset(Py_BuildValue(""));
 > }}}
 >
 > Should it be just py_ReturnNone?

 I borrowed that from `ConfigurableClientList_find`, but that returns three
 objects, while `ConfigurableClientList_getZoneTableAccessor` returns one,
 so I simplified out the `PyObjectContainer`.

 > If the python methods are named `get_zone_table` and `get_zones`, the
 C++ wrapper functions should be renamed accordingly.

 I renamed the python methods to match the C++ methods.

 > The indentation looks wrong here. Is it a tab?:
 >
 > {{{
 > +    def test_get_zone_table(self):
 > +        """
 > +       Test that we can get the zone table accessor and, thereby,
 > +        the zone table iterator.
 > +        """
 > }}}

 No, just a fat finger.

 > The commented out includes should probably be removed.

 I meant to do that, just forgot at 3am.

 > The reset here is because it needed to be deleted before the base
 object. If there is no base object (and unless you need to return it, as
 mentioned above), it is useless:
 >
 > {{{#!c++
 > void
 > ZoneTableAccessor_destroy(PyObject* po_self) {
 >     s_ZoneTableAccessor* const self =
 >         static_cast<s_ZoneTableAccessor*>(po_self);
 >     // cppobj is a shared ptr, but to make sure things are not destroyed
 in
 >     // the wrong order, we reset it here.
 >     self->cppobj.reset();
 >     Py_TYPE(self)->tp_free(self);
 > }}}

 There is now a base object chain from iterator to accessor to client list,
 so I think this can stay.

 > '''Documentation'''
 >
 > This still talks about accessors:

 Renamed zone_table back to accessor, so this can stand.

 > This includes `base_obj` in the description, but the parameter is not
 there:

 Fixed the implementation (and the prototype).

 >
 > This talks about C++, while the documentation is for python:
 >
 > {{{#!c++
 > const char* const ZoneTableIterator_doc = "\
 > Read-only iterator to a zone table.\n\
 > \n\
 > You can get an instance of the ZoneTableIterator from the\
 > ZoneTableAccessor.get_iterator() method. The actual concrete\
 > C++ implementation will be different depending on the actual data
 source\
 > used. This is the abstract interface.\n\
 > }}}

 Ah, that was a direct cut-and-paste from `ZoneIterator_doc`, which passed
 review a couple years ago.

 Still, I take your point. For now, I've just removed the mention of C++.

-- 
Ticket URL: <http://bind10.isc.org/ticket/2908#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development


More information about the bind10-tickets mailing list