[Yum] code cleanup: one function in one source

[Vladimir Bormotov]

		Hi, Michael!

>>>>> "MS" == Michael Stenner <mstenner at phy.duke.edu> writes:

>>  and, please, no import inside functions (look at 'import rpm' in this
>>  grep output and many-many-many import string/os/sys/etc in other
>>  sources)...
>>
>>  PythonStyleGuide (http://www.python.org/peps/pep-0008.html):
>>
>>    Imports
>>     - Imports are always put at the top of the file, just after any
>>       module comments and docstrings, and before module globals and
>>       constants.

 MS> I'm not going to defend the yum examples specifically, because I
 MS> haven't even looked at them, but I feel strongly that this should not
 MS> be interpreted as an absolute rule.

 not absolute.  But very strong.

  
 MS> I agree that it usually makes code much more readable, and that is
 MS> good.
 
 MUCH.  I think.

  
 MS> However, there are some situations which outrank that benefit.

 MS> 1) In some cases, the program may not know until runtime if certain
 MS>    modules will be present.

 yum at this case?  NO.  We can skip this from discussion ;)

  
 MS>    An example is a cross-platform program that has a copy_file
 MS>    function.  On windows/unix, you use the copy function from the
 MS>    shutil module.  On a mac, you use the copy function from
 MS>    macostools.  macostools doesn't exist on a linux install, so you
 MS>    can't just import it at the top of a file.

 I can.  example from real crossplatform code (not from yum)
 
 at top of file:
 
    if sys.platform == 'cygwin':
        print "Cygwin does not grok locales"
        print "produced files may have wrong formatting"
    elif os.name == 'nt':
        locale.setlocale(locale.LC_CTYPE, '.%s' % WIN_CP)

 this is right place to any import, and other platform specific code.   
 For "fast writed code".  For "long-play, code" - platform specific code
 must be wrapped, and moved out from main project sources, into modules.
 As result, main code import one module at any platform.  Small portions of
 platform specific code in each module will be more readable.  

  
 MS>    Sure, you could try and import the module and catch the exception,
 MS>    but I think it's cleaner to determine what platform you're on, and
 MS>    then import the appropriate modules and set up the functions
 MS>    appropriately.

 of course, try-import-except-import not so good.  But, again - yum not in
 this case, and local import in specific function no so good too.
 
 
 MS> 2) Efficiency.  If there is a function that needs some heavy modules,
 MS>    but will rarely be called (ie only when the program is being
 MS>    invoked in some weird mode), 

 ok.   at yum sourcetree.  
 
 grep import *py 
 
 Look inside.  Any heavy modules?  Just say, which module we can classify
 as "heavy module". 
 
 
 MS>    then it may make sense to import from within that function.  
 
 "function"..  Why function?  Python is an Object-Oriented language.   
 No functions.  Classes ;)
 
 
 MS>    This way, the modules are never loaded if they're not needed.  This
 MS>    is similar to Just In Time interpretation in a number of ways.

 If we see some "rarely called" function, we see "poor programm design".
 This function must be moved into separate class.  Class moved into module,
 and "heavy module" import once here.  At top ;)
 
 
 MS> Python is very good about efficiently dealing with re-imports (it
 MS> doesn't just import it again) so function/class level imports have
 MS> little cost except readability.  
 
 readability - big cost.   Human resources - very big cost. 
 
  
 MS> Even there, it sometimes ADDS readability in that it says "most of
 MS> this module doesn't use string and re, just this function/class does".

 
 No.  If "rarely called" function not moved out from module, we have "poor
 programm design".  Readabilty of "poor designed programm" not interested.
 Who whant read poor designed programm?  Who want use programm, with poor
 design? 

  
 MS> Again, I'm not commenting on the specific yum cases, and I do like the
 MS> general rule.  I'd guess that 98% or more of my imports appear at the
 MS> top of modules.
 
 ;-)
 
 
 MS> I just don't like it as a universal rule.

 I think, in code cleanup phase "Code Style" is a general rules.  Any "not
 styled" code must be "styled" or moved out.
 
 
-- 
		Bor.