BIND 10 #2437: python wrapper for validateZone

BIND 10 Development do-not-reply at isc.org
Mon Jan 7 21:56:25 UTC 2013


#2437: python wrapper for validateZone
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130108
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:5 vorner]:

 > Is the code really only a single commit (and a bunch of merges before)?
 I'm
 > just making sure I checked everything.

 Yes.  It could have been separated into multiple commits, but I simply
 didn't find reasonable chunks (or I was simply a bit lazy).
 >
 > Also, few small points.
 >
 > The constructor of tests, it is counter-intuitive for
 `find_result=False` to
 > mean „act normally“. I'd propose `None`, but it is actually used to be
 returned
 > somewhere. But even `True` might be better.

 Okay, I changed it to a string 'use_default'.  It should be clearer.

 > We should test throwing from the callbacks (since the exception must be
 > manually carried through a bunch of python←→C++ layers). It would be
 nice if
 > the actual exception would be preserved, which is, I think, possible.

 Hmm, I'm not sure what specifically you are suggesting.  Is this
 something not covered in test_check_callback_fail?

 > With the optional parameters, does it initialize them to NULL (or,
 `Py_None`)
 > or leaves them as they are? In the second case, the variables could be
 used
 > uninitialized:
 >
 > {{{#!C++
 >         PyObject* po_name;
 >         PyObject* po_rrclass;
 >         PyObject* po_rrsets;
 >         PyObject* po_error;
 >         PyObject* po_warn;
 >
 >         if (PyArg_ParseTuple(args, "OOO(OO)", &po_name, &po_rrclass,
 >                              &po_rrsets, &po_error, &po_warn)) {
 > }}}

 There's no optional parameter here.  If you meant the "(OO)" part,
 it means it's a tuple of two objects.  Nevertheless, I don't mind
 setting the po_xxx to NULL f you want.

 > And, I fixed a missing `EXTRA_DIST`, it is pushed to the branch.

 Ack, thanks.

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


More information about the bind10-tickets mailing list