[Top][All Lists]
[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.