gnulib-tool-py
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnulib-tool-py] func_warning


From: address@hidden
Subject: Re: [gnulib-tool-py] func_warning
Date: Fri, 13 Jul 2012 12:08:29 +0000

Hi Bruno,

it seems that I couldn't tell you what I want, so I've just pushed the code to 
show what I mean. The files you need are gnulib-tool.py[1], GLError.py[2] and 
GLImport.py[3]. You may also need m4 package.

As you may see from [1], I've moved the execution to function main(). I've also 
enabled lgpl flag. See lines 286-292: we catch any GLErrorHandler error which 
can happen and store its parameters. Then we create GLError instance with 
parameters what we need.

Go to file [2] and see lines 104-188: here we define what GLError will do for 
different parameters if style=0 (i.e. we use old style).

Go to file [3] and see lines 481-500: here we work with licenses. Then we raise 
GLErrorHandler if there are any incompatibilities with licenses and we send 
list of tuples to GLErrorHandler. It would have been raised, but see file [1]: 
we catch such errors!

Now go to file [2] to see again how our GLErrorHandler with code 11 and tuples 
will be processed to show old gnulib-tool error (lines 170-188).

To see what happens just run gnulib-tool.py inside m4 package directory.

So what this mechanism provides?
1. We don't need to catch and process errors in other files except 
gnulib-tool.py.
2. We have separated shell errors and Python errors.
3. Most user still can just catch GLErrorHandler if they write their scripts 
from zero. We just assume GLError for gnulib-tool.py, so users can use it or 
not.

The only minus is that it may be a bit overkilling to define GLError class for 
it: we can just make a function like new_errors_to_old_errors. I really dislike 
GLErrorHandler name, I'd rather prefer just GLError for Pythonic error class.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]