py_compile does not re-raise exceptions so that they
can be caught by the calling program. The following
example illustrates the problem:

-----begin bad_prog.py-----
print "hello
-----end   bad_prog.py-----


-----begin test_compile.py-----
from py_compile import compile

class CompileError(Exception): pass

fl = 'bad_prog.py'
try:
    compile(fl)
except Exception,msg:
    raise CompileError, '%s: %s' % (msg,fl)
-----end   test_compile.py-----

-----
[~]:python test_compile.py 
  File "bad_prog.py", line 1
    print "hello
               ^
SyntaxError: invalid token
-----
Note that CompileError is not raised.


The attached simple patch should take care of the
problem (and I hope not cause any bad side effects). 

Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

Logged In: YES 
user_id=679947

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

Logged In: YES 
user_id=679947

Sorry, the file should be attached now. I find the SourceForge 
web interface a little confusing.

-g

Logged In: YES 
user_id=21627

This patch is wrong: Callers of py_compile.compile, such as
py_compile.main, now need to catch potential exceptions. As
this is an incompatible change, you need to provide
documentation, and ideally a migration strategy.

It is also unclear why you both print the exception and
raise it: If an exception is raise, it is normally the
responsibility of the caller to print the exception.

Logged In: YES 
user_id=679947

Thank you for the comments. 
I was trying to maintain some aspects of the current behavior and 
add the necessary exception raise. Clearly, this is not correct. 
I'll give this patch more thought and consider issues of 
documentation and migration as well. 

Logged In: YES 
user_id=679947

The following patch adds a 'PyCompileError' exception to
py_compile and adds the appropriate 'except' and 'raise'
clauses to py_compile.py, compileall.py, and zipfile.py (I
think that these are the only affected files in the standard
library).
The exception class messages were chosen to try to simulate
the current behavior in these files as closely as possible.

If this patch looks okay (or at least is in the right
direction), I'll begin to look at the documentation and
migration issues.

Logged In: YES 
user_id=21627

The patch looks fine so far, except for a few minor issues
(i.e. never to use bare except: clauses). You don't have to
implement a migration strategy: just elaborating it here
would be fine. To preserve compatibility, I could envision a
flag ('doraise' or some such), or a different entry point.
If you manage to provide full backwards compatibility, you
don't need to change any of the existing callers.

Logged In: YES 
user_id=679947

I have implemented a 'doraise' flag in py_compile.compile.
I think the patch should now be backwards-compatible.
However, I think that files that use py_compile in the
standard library (compileall.py and zipfile.py) should
perhaps use the new exception mechanism for clarity and as a
demonstration of how to use the exception.
What do you think?
I'm not sure if I've eliminated the 'few minor issues'. I
did  implement 'except Exception:' instead of a raw
'except:'. Is this what you meant.
Thanks for your comments.

Logged In: YES 
user_id=21627

I'm still unsure why you replace the except SyntaxError: with 
except Exception:. What other exceptions could occur in this 
place? Also, calling exc_info isn't necessary - you could 
obtain the exception value in the catch clause. Unless you 
are expecting string exceptions (which ones), code to 
support string exceptions should not be needed, and the type 
can be obtained by looking at __class__.

Don't compare types by comparing their names: to find out 
whether t is SyntaxError, write 't is SyntaxError', 
not 't.__name__ == "SyntaxError"'.

Exception instances should always have a .args attribute. 
This is best generated by calling the base class __init__ in 
an exception's __init__.

Please provide the documentation changes (docstrings, 
Doc/lib, and a NEWS entry) as well.

Logged In: YES 
user_id=679947

I changed 'except SyntaxError:' to 'except Exception:' since
compileall.py has the 'except:' clause in the following:
                try:
                    ok = py_compile.compile(fullname, None,
dfile)
                except KeyboardInterrupt:
                    raise KeyboardInterrupt
                except:
                    # XXX py_compile catches SyntaxErrors
                    if type(sys.exc_type) == type(''):
                        exc_type_name = sys.exc_type
                     ...

If this block is not necessary, then I can simplify things
somewhat. The test for string exceptions was taken from here
as well. 

Should I assume that only class-based and SyntaxError
exceptions can occur from __builtin__.compile? 
(I looked at compile.c, and from my
non-c-programmer-perspective, it looks like other exceptions
can be raised. _If I read the code correctly_, it looks like
ValueError, MemoryError, OverflowError, and SystemError can
also occur.)

Attached is the latest diff with most of your suggestions
implemented. I'll work on the documentation.

Logged In: YES 
user_id=21627

You are probably right that other errors can occur in
compile also. However, KeyboardInterrupt must pass through
unmodified, since the user must be able to interrupt
compilation.

Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

Logged In: YES 
user_id=679947

Attached is a patch that includes changes to the source and
documentation.

Logged In: YES 
user_id=21627

Thanks for the patch. Committed as

libpycompile.tex 1.4
compileall.py 1.13
py_compile.py 1.24
zipfile.py 1.28
NEWS 1.616
ACKS 1.224