Re: OperatingSystem.py

On Mon, Sep 01, 2003 at 12:04:46PM +0200, Bram Moolenaar wrote:
> 
> Tim Hemel wrote:
> 
> Thanks.  Seeing the code organised this way I spot a few things that
> need to be improved.  That means it's a good idea to do it.  I'll make a
> few specific remarks below.
> 
> Problem with these things is that with Python it's often a lot quicker
> to write the code yourself than to search around for existing code...

True.

> > Prepare for more...
> 
> We at least need the diffs for the places that use the new class!

Ok, I only wrote this as a suggestion, not an actual implementation. Now 
that I know how to test the program (the code is well covered with unit tests
I hope?) I can actually implement it. What I did was make a function and in
the comments list the lines where it was used.

> > import os
> > 
> > # suggestions:
> > #
> > # for shorten_name, use relative path script:
> > # http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/208993
> > #
> > # for dir_contents, use os.listdir instead of glob
> 
> Is there a specific reason to use os.listdir() instead of glob()?

os.listdir is more portable, and you do not have to do a glob('.*')
if os.name == 'posix'. That makes the code less iffy.

> This is specifically used to decide whether to invoke "tee".  I don't
> see another use for it.
> 
> >         # but perhaps it is better to abstract the code that is used after
> >         # this...
> 
> This is one of those cases where moving the code is doubtful.  You might
> end up implementing redir_system() in the operating system class, which
> is probably not a good idea.

My reasoning was: it is used in more than one place, and seems to be an
essential decision, therefore it should be in the class.

> >     def getFullFname(self,name):
> 
> Please use a space after a comma, that makes it much easier to read.

Ok. Is there a page with a-a-p coding conventions?

> >     def systemAsync(self,cmd):
> >         if not os.fork():
> >             n = os.system(cmd)
> >             os._exit(n)
> 
> This is quite inefficient, forking the whole Python interpreter and not
> doing an "exec" right away...  Can't be solved easely, trying to avoid
> using it is probably the best solution.

I just copied it from the original...

> > That is indeed so simple that I would have never thought of it.
> 
> This might be a good opportunity to add tests for those things that are
> changed.  Joerg Beyer has created a start for the unittests, we should
> be adding more tests now!
> 

Tim

-- 
Zen Microsystems: we're the om in .commmmmmmmm...


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf