[Python-Dev] Proposed new module for the Python library

[Greg Ward]

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.