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

[BIND 10 Development]

#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-20130219
         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

 Replying to [comment:17 jinmei]:
 > I don't necessarily oppose to that, but at this time I'd rather avoid
 > including mostly-unused file.  Realistically, I suspect there are yet
 > very few people using this Python library for development other than
 > ourselves.

 Hmm, OK. It does make some sense not to put it to the git repo, as we'd
 have it there for long time (since we would forget). But maybe noting in
 the changelog a script can be downloaded from the trac site, at least? I
 know there are not many people who use it, but there might be few.

 > > The tests fail for me:
 > > {{{
 > > Running test: session_tests.py
 > > ...F..........F..........................
 > > ======================================================================
 > > FAIL: test_convert_rrset_class (__main__.SessionModuleTests)
 > > }}}
 >
 > As I responded separately, I couldn't reproduce it, and I suspect it
 > was because your build environment is incomplete.

 I don't know, but it does not fail now. So I guess it must have been
 something like this, though I usually start with completely clean checkout
 for each review now (I have a script that checks out a new directory and
 does full build and tests).

 > > 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?
 >
 > I guess you (at least) meant generate_typeclasscode(), where we built
 > the auto-generated code by extending a string object.  I'm not sure if
 > the internal implementation is that inefficient, and even if so, if it
 > matters in this usage.  But I revised the code to what I guess you
 > would have envisioned.

 I did mean that one, yes. However, it might have been that I misunderstood
 the code, I though the generate_typeclasscode was called for each type and
 each class (so many many times), each time overwriting the file. I wasn't
 really worried about the speed of the in-memory string handling, just
 about the writes to the file.

 But reading it again, it seems it is called just once for all types and
 once for all classes, so it doesn't matter. But maybe this way is simpler
 to read anyway.

 > > 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?
 >
 > Hmm, I once considered that approach and at that time it seemed to
 > require heavier updates to the generator script.  But on looking at it
 > again it seems to be quite straightforward.  So I adopted the idea
 > (but instead of introducing a separate file, simply listing them in
 > the generator script), removing the placeholder files.

 Thanks

 It looks OK to merge now, I think.

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