On 02 August 2001, Eric S. Raymond said:
> There is a common `compiler-like' pattern in Unix scripts which is useful
> for translation utilities of all sorts. A program following this pattern
> behaves as a filter when no argument files are specified on the command
> line, but otherwise transforms each file individually into a corresponding
> output file.
Sounds like a useful tool to have around. I'm not sure the name
'ccframe' conjures up images of the above paragraph, but I'm not sure
what name *does*. This is the hardest sort of software to name!
> Design comments? Critiques? Code on request.
>
> I'm already considering throwing exceptions on open and rename errors
> instead of complaining to stderr and returning an error status. That
> would be more Pythonic, though slightly less convenient in the
> commonest cases.
How to handle failure to open an input file depends on circumstances:
* sometimes, it is utter calamity, and raising an exception is the
right thing to do
* sometimes, it's a user-level error, and
try:
file = open(filename)
except IOError, err:
sys.exit("%s: %s" % (filename, err.strerror))
is the right thing to do
* sometimes, it's just something the user ought to know about, and
the "except" clause above can be turned into
sys.stderr.write("warning: %s: %s" % (filename, err.strerror))
continue # next file, please
* conceivably, it's something you can just ignore
IOW, I think this should be an option for users of the framework. The
default should be to throw an exception -- kaBOOM! For me, the middle
two options would be most commonly used, but modules should not
sys.exit() or sys.stderr.write() unless they are explicitly told to do
so.
Greg
--
Greg Ward - nerd gward@python.net
http://starship.python.net/~gward/
My opinions may have changed, but not the fact that I am right.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4