BIND 10 #756: Python logging - produce API

[BIND 10 Development]

#756: Python logging - produce API
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jelte
  stephen                            |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20110628
                   Priority:  major  |            Resolution:
                  Component:         |             Sensitive:  0
  logging                            |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4.0
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jelte


Comment:

 Replying to [comment:7 jelte]:
 > One general thing, for the python dns wrappers, we put the code in
 src/lib/dns/python, as opposed to src/lib/python/isc/dns. Not sure which
 one is better (it is c++ code, so src/lib/<lib>/python makes sense, but it
 is for python, so src/lib/python/isc/<lib>/ also makes sense). We can
 probably move one or the other later, but we may want to discuss which to
 choose for consistency.

 It works with the dns wrappers, because they are toplevel module
 (pydnspp). But for this to work, it must be in a isc subdirectory, because
 it's called isc.log. I could put it into src/lib/log/python/isc/log, but
 that seemed long. If you think it is better, I can move it.

 > src/lib/python/isc/log/__init__.py:
 >
 > just wondering, does the pythonpath setting in the make check target not
 work or is that not enough?

 It isn't enough. If it is installed, it is in isc/log.so, when it is
 tested, it is in isc/log/log.so, so the module would have to be called
 isc.log.log. This way, the isc.log itself is considered a module, because
 it has the __init__ module in it and this one loads everything into
 itself, making it available as isc.log. I admit, this is quite a bit of
 juggling.

 > perhaps if you want to enforce that set_test_dictionary() gets a bool
 you could use PyBool_Check();
 > for instance like this, it will throw if the argument is not True or
 False:

 If I want to make the function act in a python way, I don't. If you have a
 python code
 {{{#!python
 def function(x):
         if x:
                 print("Hello")
 }}}

 And pass 42 to it, it happily greets you instead of throwing an exception.
 This way, the code acts the same and is acting in the python duck-typing
 way.

 > reset():
 > (regarding the comment) you don't need to check whether there are no
 arguments here, as the methods array already specifies METH_NOARGS for
 this one (so it'll raise a type error if any arguments are given)

 Removed. The comment was older than my knowledge of METH_NOARGS.

 > severityToText():
 > Should we move severityToText() to the cpp api? (we do have text to
 severity there)

 I don't know. Even the text to severity is internal one (and this one just
 misuses it, because it's after all part of the logging library), and this
 one is not needed there. But if you think it makes sense even for internal
 function that isn't needed anywhere else.

 > As discussed on jabber, perhaps we should prepend those testing/internal
 functions in the module with a _.

 Unfortunately, this does not work. Python seems to be more strict with
 module-level private functions, if they start with an underscore, it
 doesn't copy them at all to the publicly available dict and it tells me
 the method doesn't exist from within the tests.

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