BIND 10 #2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor

BIND 10 Development do-not-reply at isc.org
Tue Jun 11 02:27:57 UTC 2013


#2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  vorner
            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
-------------------------------------+-------------------------------------
Changes (by pselkirk):

 * owner:  pselkirk => vorner


Comment:

 Replying to [comment:13 vorner]:

 > First, may I suggest that you make smaller commits next time?

 Okay.

 > > I renamed the python methods to match the C++ methods.
 >
 > That wasn't what I was suggesting. I don't have strong opinion on that,
 but what I originally thought was to not stop the rename
 `95af51c86a9d480562526421863e47df7260e6a3` halfway through, but complete
 it with renaming functions like
 `ConfigurableClientList_getZoneTableAccessor` too.

 Ah. That decision was made in #2907 (and #2906, where the originally
 proposed `ZoneTable` class was renamed `ZoneTableAccessor`).

 > What use is the get_current method now? Isn't it enough to keep the
 function as internal helper and not show it? Can you show a bit of python
 code where the method would be of any use?

 All right. I'm not really attached to `get_current`, and `get_next_rrset`
 wasn't a good model to follow. So we'll strip it down to just the python
 iterator.

 > Also, the point with not needing get_iterator() was not addressed (or I
 didn't notice). Is it on purpose or did you overlook it? Also, if it's on
 purpose, can you share the reason for not agreeing on that?

 As I understand it, `get_zone_table_accessor()` will eventually provide
 methods to add and remove zones, but for now it only exists to get the
 iterator. It sounds like you want to merge `get_zone_table_accessor()` and
 `get_zone_table_iterator()` into one method like `get_zone_table()` which
 would hide the complexity of the C++ classes. I'm not sure how to answer
 that, because I'm not sure how these methods fit into the plan for the
 Python interface going forward.

 > And, I pushed a very small fix of whitespace. Also, we usually write
 this test:
 >
 > {{{#!python
 > self.assertEqual(origin.to_text(), "example.org.")
 > }}}
 >
 > in the reverse form:
 > {{{#!python
 > self.assertEqual(origin, isc.dns.Name("example.org"))
 > }}}

 Okay, thanks.

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


More information about the bind10-tickets mailing list