SyntaxError.__init__() checks for the `print` and `exec` error cases where the user forgot to use parentheses:

>>> exec 1
  File "<stdin>", line 1
    exec 1
         ^
SyntaxError: Missing parentheses in call to 'exec'

>>> print 1
  File "<stdin>", line 1
    print 1
          ^
SyntaxError: Missing parentheses in call to 'print'

However, this check is also applied to *subclasses* of SyntaxError:

>>> if True:
... print "Look ma, no parens!"
  File "<stdin>", line 2
    print "Look ma, no parens!"
        ^
IndentationError: Missing parentheses in call to 'print'

and

>>> compile('if 1:\n    1\n\tprint "Look ma, tabs!"', '', 'single')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "", line 3
    print "Look ma, tabs!"
                         ^
TabError: Missing parentheses in call to 'print'

Perhaps the check needs to be limited to just the exact type.

Credit for uncovering this gem: https://stackoverflow.com/questions/45591883/why-is-an-indentionerror-being-raised-here-rather-than-a-syntaxerror

I'm not sure whether this is a bug or a feature.

In the examples you show, we have *both* an IndentationError/TabError and missing parentheses around print. So I'm almost inclined to say that this is right:

- you get an IndentationError (or TabError);

- and the error message *also* tells you that print is missing parens.

Two errors for the price of one!

I'm not sure that I would have designed it this way from scratch, but given that it already exists I'm not sure that it should be "fixed".

In any case, since the error message itself is not part of the public API, I don't think there's any problem in changing it in a bug-fix release. So *if* we change this, we can change it in 3.6.

It's confusing; a syntax error reports on the first error found, not two errors at once. The TabError or IndentationError exception detail message itself is lost (it should be "IndentationError: Improper mixture of spaces and tabs." or "TabError: Improper indentation.", respectively). So you end up with an end-user scratching their head, the two parts of the message make no sense together.

> Perhaps the check needs to be limited to just the exact type.

Looks reasonable to me. Do you want to provide a PR Martijn?

> > Perhaps the check needs to be limited to just the exact type.
> Looks reasonable to me. Do you want to provide a PR Martijn?

You realise that is making the current traceback *less* informative 
instead of more informative? I think that's going backwards -- useful 
information about the syntax errors are being discarded. "Practicality 
beats purity" -- the current behaviour is helpful, even if it mixes 
information about two errors into one traceback.

The current traceback is incorrect. It mixes exception type and message from different errors.

This does not increase clarity. It creates confusion.

There are two distinct syntax errors, and they should be reported separately, just like `print "abc" 42` is two syntax errors; you'll hear about the second one once the first one is fixed.

Disregard my last message, I misread Serhiy's sentence (read 'correct' for 'incorrect').

New changeset 680f04a926bce04e4320ba883068c345eba502a6 by Łukasz Langa (Martijn Pieters) in branch '3.6':
bpo-31161: only check for parens error for SyntaxError (#3083)
https://github.com/python/cpython/commit/680f04a926bce04e4320ba883068c345eba502a6

New changeset 772d809a63f40fd35679da3fb115cdf7fa81bd20 by Łukasz Langa (Martijn Pieters) in branch 'master':
bpo-31161: only check for parens error for SyntaxError (#3082)
https://github.com/python/cpython/commit/772d809a63f40fd35679da3fb115cdf7fa81bd20