Re: BIND 10 #322: Process name in Python

BIND 10 Development do-not-reply at isc.org
Thu Sep 23 08:18:30 UTC 2010


#322: Process name in Python
-------------------------------+--------------------------------------------
      Reporter:  fujiwara      |        Owner:  vorner   
          Type:  enhancement   |       Status:  reviewing
      Priority:  major         |    Milestone:           
     Component:  Unclassified  |   Resolution:           
      Keywords:                |    Sensitive:  0        
Estimatedhours:  0.0           |        Hours:  0        
      Billable:  1             |   Totalhours:  0        
      Internal:  0             |  
-------------------------------+--------------------------------------------
Changes (by jinmei):

  * owner:  UnAssigned => vorner


Comment:

 '''general comments'''
  - please provide suggested ChangeLog entry.
  - I'm afraid the library name "bind10" maybe misleading because it sounds
 like something related to the bind10 process.  I have no specific idea
 about a better name, but something like "util"?
  - Likewise, I suspect "rename" is too generic.  We see in the program
 code:
 {{{
 import isc.bind10.rename
 isc.bind10.rename.rename()
 }}}
  and it's not obvious that it renames the process title.

 '''configure.ac'''
  - I'd clarify "--disable-setproctitle-check" is about a python library,
 either or both in the option name and option description.

 '''rename.py'''
  - please add the copyright notice
  - please describe this is a wrapper interface to the setproctitle
 library.
  - it strips path to the program name by default, so we'll see "bind10"
 instead of "/usr/local/sbin/bind10", etc.  Personally, I'd like to know
 the latter, because I may have multiple different versions installed in
 different places and I'd like to distinguish them.

 '''bind10/tests/Makefile.am'''
  - you don't need the LIBRARY_PATH hack for this test.  it's necessary
 only for those that require our C++ loadable modules.

 '''tests/rename.py'''
  - we normally call files for tests "xxx_test.py" (it's redundant because
 the directory name indicates it's related to tests.  but on the other hand
 it helps to separate real test code and other helper files).  it's not a
 strong requirement, but unless you strongly want to keep this naming I'd
 suggest follow the convention for consistency.
  - some methods are named "__xxx".  in other python code we generally seem
 to use "_xxx".  I don't know which one is the standard way, but it's
 better to be consistent.
  - __scan(): variable repl doesn't seem to be used.
  - __scan(): according to the manual assert_ is deprecated by
 assertTrue().

 ''' tests/rename.py:TestRename.test_calls()'''
  - I respect the paranoia:-), and I actually like it, but I suspect this
 is beyond the scope of unit tests.
  - more practically, this (at least currently) doesn't work if you try
 'make check' for a vanilla tree.  so, I'd suggest this test is separated
 as part of some kind of "distcheck" level check.
  - the regular expression "lines" is difficult to understand.  Why \\w
 instead of \w?  same for \\s, and what does \\\\\\n mean?  If it can be
 simplified, please do so.  And in any case, I think this requires a
 descriptive comment.
  - os.walk(): I don't like to hardcode the path for the 1st argument.  I'd
 use top_srcdir and have the configure script replace it.
  - os.walk(): do we really need to follow symbolic links (despite the risk
 of causing an infinite loop)?
  - what's the purpose of second variable (_) in the for ... findall idiom?
 e.g.
 {{{
 +                for (var, _) in lines.findall(makefile):
 }}}
  it seems to me it could simply be for var in lines.findall(makefile)

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


More information about the bind10-tickets mailing list