BIND 10 #1866: isc.dns constants like RRType.A() should be constants, not functions

BIND 10 Development do-not-reply at isc.org
Mon Feb 4 10:04:58 UTC 2013


#1866: isc.dns constants like RRType.A() should be constants, not functions
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130205
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 First, would it make sense to put the script to convert into the
 repository, let's say to the tools directory? In case some user already
 used our libraries, it might be useful for them. We should, of course,
 make it clear it is not supported in any way.

 I think the convention how to keep empty git directories is to place a
 `.keep` file there, not `gitignore`. The `.gitignore` has special meaning
 for git and it feels a bit like an abuse.

 The tests fail for me:
 {{{
 Running test: session_tests.py
 ...F..........F..........................
 ======================================================================
 FAIL: test_convert_rrset_class (__main__.SessionModuleTests)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/tmp/bind10-1/bind10-20121219/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 136, in test_convert_rrset_class
     str(rrset3))
 AssertionError: 'www.example.org. 3600 NONE A \\# 4
 c0000201\nwww.example.org. 3600 NONE A \\# 4 [truncated]... !=
 'www.example.org. 360
 0 CLASS254 A \\# 4 c0000201\nwww.example.org. 3600 CLASS254 [truncated]...
 - www.example.org. 3600 NONE A \# 4 c0000201
 ?                       ^^^^^
 + www.example.org. 3600 CLASS254 A \# 4 c0000201
 ?                       ^^ +++++++
 - www.example.org. 3600 NONE A \# 4 c0000202
 ?                       ^^^^^
 + www.example.org. 3600 CLASS254 A \# 4 c0000202
 ?                       ^^ +++++++


 ======================================================================
 FAIL: test_convert_rrset_class (__main__.SessionTest)
 ----------------------------------------------------------------------
 Traceback (most recent call last):
   File
 "/tmp/bind10-1/bind10-20121219/_build/../src/lib/python/isc/ddns/tests/session_tests.py",
 line 405, in test_convert_rrset_class
     str(rrset3))
 AssertionError: 'www.example.org. 3600 NONE A \\# 4
 c0000201\nwww.example.org. 3600 NONE A \\# 4 [truncated]... !=
 'www.example.org. 3600 CLASS254 A \\# 4 c0000201\nwww.example.org. 3600
 CLASS254 [truncated]...
 - www.example.org. 3600 NONE A \# 4 c0000201
 ?                       ^^^^^
 + www.example.org. 3600 CLASS254 A \# 4 c0000201
 ?                       ^^ +++++++
 - www.example.org. 3600 NONE A \# 4 c0000202
 ?                       ^^^^^
 + www.example.org. 3600 CLASS254 A \# 4 c0000202
 ?                       ^^ +++++++
 }}}

 It is not code from the branch, but this regexp seems to be wrong (missing
 a dot after the backslash). It is in the generator script:
 {{{#!python
 elif re.search('\cc$', file):
 }}}

 Why do you generate the code into a variable and accumulate it across all
 the RRtypes and then dump it after each new one? This seems like a
 quadratic run time and it looks unnecessary. Would it make sense to output
 it just once at the end?

 Would it be more lightweight and easier to read if the list of „fake“
 types (the ones that don't exist or we don't have them implemented yet)
 would be by a single file with a list instead of many effectively empty
 files?

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


More information about the bind10-tickets mailing list