only raise ImportError out of imports
Currently, if module 'eggs' has bad syntax and you import it from module 'spam', then you will get a SyntaxError in module spam: --------------------------------------------------------- $ cat > eggs.py << EOF a + EOF $ cat > spam.py << EOF import eggs EOF $ python -c 'import spam' Traceback (most recent call last): File "spam.py", line 2, in <module> import eggs File "/tmp/eggs.py", line 1 a + ^ SyntaxError: invalid syntax --------------------------------------------------------- My proposal is that, instead, an error during import always results in an ImportError. So in the above example, the error would have been an ImportError rather than a SyntaxError. However, rather than ignore the cause of the import error, we would use exception chaining to save the SyntaxError. To get this effect currently would look something like this: --------------------------------------------------------- $ cat > spam.py << EOF try: import eggs except SyntaxError as e: raise ImportError("failed to import eggs") from e EOF $ python -c 'import spam' Traceback (most recent call last): File "spam.py", line 2, in <module> import eggs File "/tmp/eggs.py", line 1 a + ^ SyntaxError: invalid syntax The above exception was the direct cause of the following exception: Traceback (most recent call last): File "spam.py", line 4, in <module> raise ImportError("failed to import eggs") from e ImportError: failed to import eggs --------------------------------------------------------- With exception chaining the SyntaxError is stored on the ImportError: --------------------------------------------------------- $ cat > ham.py << EOF try: import spam except ImportError as e: print("cause: {}".format(e.__cause__)) print("context: {}".format(e.__context__)) EOF $ python ham.py cause: invalid syntax (eggs.py, line 1) context: invalid syntax (eggs.py, line 1) --------------------------------------------------------- The main benefit of this change would be to isolate errors during import to the module where they happen. The main challenge would be with backward compatibility, so I won't hold my breath to see this in Python 3. While all feedback is welcome, I'd particularly like to hear from those that actually use non-ImportError exceptions that come out of the import statement. Thanks! -eric
On Tue, Jul 31, 2012 at 3:49 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
The main benefit of this change would be to isolate errors during import to the module where they happen. The main challenge would be with backward compatibility, so I won't hold my breath to see this in Python 3.
While all feedback is welcome, I'd particularly like to hear from those that actually use non-ImportError exceptions that come out of the import statement. Thanks!
The problem specifically with doing this for SyntaxError is that you would break every interactive interpreter out there (including the default one). They rely on seeing the SyntaxError directly in order to highlight the offending piece of syntax. Also dig into pkgutil - that broke when I started tinkering with this kind of thing while migrating it over to using importlib. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Jul 31, 2012 at 12:00 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Tue, Jul 31, 2012 at 3:49 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
The main benefit of this change would be to isolate errors during import to the module where they happen. The main challenge would be with backward compatibility, so I won't hold my breath to see this in Python 3.
While all feedback is welcome, I'd particularly like to hear from those that actually use non-ImportError exceptions that come out of the import statement. Thanks!
The problem specifically with doing this for SyntaxError is that you would break every interactive interpreter out there (including the default one). They rely on seeing the SyntaxError directly in order to highlight the offending piece of syntax.
Also dig into pkgutil - that broke when I started tinkering with this kind of thing while migrating it over to using importlib.
Cool. I'll have a look. -eric
On 7/31/2012 1:49 AM, Eric Snow wrote:
Currently, if module 'eggs' has bad syntax and you import it from module 'spam', then you will get a SyntaxError in module spam:
--------------------------------------------------------- $ cat > eggs.py << EOF a + EOF $ cat > spam.py << EOF import eggs EOF $ python -c 'import spam' Traceback (most recent call last): File "spam.py", line 2, in <module> import eggs File "/tmp/eggs.py", line 1 a + ^ SyntaxError: invalid syntax ---------------------------------------------------------
This is really clear to me. SyntaxError in eggs exposed during the import call, which obviously failed, as does everything in a traceback.
--------------------------------------------------------- $ cat > spam.py << EOF try: import eggs except SyntaxError as e: raise ImportError("failed to import eggs") from e EOF $ python -c 'import spam' Traceback (most recent call last): File "spam.py", line 2, in <module> import eggs File "/tmp/eggs.py", line 1 a + ^ SyntaxError: invalid syntax
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "spam.py", line 4, in <module> raise ImportError("failed to import eggs") from e ImportError: failed to import eggs ---------------------------------------------------------
Much worse. Lots of extra noise with the important part buried in the middle. I don't see the point of privileging import calls over everything else in the call chain. An ImportError should be related to an import-specific cause, and SyntaxError is not such. It would be there anyway if eggs.py were run directly. -- Terry Jan Reedy
participants (3)
-
Eric Snow -
Nick Coghlan -
Terry Reedy