In this case I agree that a SyntaxWarning is a good idea, per Serhiy's patch. I would be even more conservative, and only warn if the first object is a tuple -- the case of the missing comma in the original example appears likely enough, but I don't expect people to write e.g. `[[1, 2], (3, 4)]` very often, so leaving the comma out there would be very unlikely.

Regarding the issue of when it's appropriate to issue a SyntaxWarning vs. when to leave it up to linters, again I would recommend great caution and only warn about code that is *definitely* going to fail when executed. (Or at least is *definitely* not going to please the programmer -- one of the first cases where we added a SyntaxWarning was actually `assert(condition, message)`, which "fails" by never failing. :-) But this is one of those cases.

On Thu, Jan 24, 2019 at 2:10 PM Neil Schemenauer <nas-python@arctrix.com> wrote:

On 2019-01-24, Terry Reedy wrote:
> Serhiy Storchaka suggested a compiler SyntaxWarning and uploaded a
> proof-of-concept diff that handled the above and many similar cases.

I believe that in general we should give better errors or warnings
if we can do it without huge difficulty. Serhiy's patch is quite
simple. The same check *could* be done by a linting tool. Putting
it in CPython will make it more widely available. These checks
could be helpful to beginners who probably won't have linting tools
setup.

I think we should not make it an error, otherwise we have changed
Python "the language". We don't want to force other Python
implementations to do the same check. It might be hard for them to
implement. So, SyntaxWarning seems like a reasonable compromise.

Regards,

Neil
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org