Since Python 3.2, input in 'exec' mode  of 'compile' does not have to end in a newline anymore. However, it creates a surprising behavior when a 'SyntaxError' is reported:>>> try: compile('try', '<string>', 'exec')... except SyntaxError as ex: print(repr(ex))... SyntaxError('invalid syntax', ('<string>', 1, 4, 'try\n'))The 'text' field of the exception thrown contains an additional newline character that was not present in the input. Is it:a. Proper Python language behavior?b. CPython implementation artifact?c. A bug?In case of:a. I will submit a patch to IronPython, which does not add an extra newline at the moment.b. I can submit a patch to CPython to make StdLib tests implementation independent.c. This inquiry can serve as a bug report.

I don't think a roundtrip is guaranteed by the parser, only producing an equivalent input.

I don't think it's option C. As for whether A or B I don't know. Wouldn't hurt to ask on python-dev if no one comes forward with a more authoritative answer.

still not able to answer the why, but at least I can answer the what here:https://github.com/python/cpython/blob/f665b96e92a6a6943e312e2c606f348db95939ab/Parser/tokenizer.c#L984-L987cpython adds a newline during tokenization if the file does not end in a newline

If "equivalent input" is acceptable, then it looks like case B: other implementations possibly having different forms of equivalent input.I am going to post this question on python-dev.

I'm assuming the real issue is wanting to make IronPython pass as much of the CPython test suite as possible. I am okay with interpretation (B) in this case -- I can totally see that other parsing strategies have no use for adding the '\n' character to the end of the string. But I don't want to declare that CPython is wrong to show the '\n' -- it seems a pretty harmless artifact. So fixing the tests to allow it either way sounds good.

> I'm assuming the real issue is wanting to make IronPython pass as much of the CPython test suite as possible.This is indeed the case. The CPython test suite is invaluable in guiding IronPython development. Most of the time, the tests are pretty good to gloss over implementation artifacts (usually error messages), so that they work for IronPython as well, despite some differences between CPython and IronPython.There are a few cases, however, when the tests expect behavior that is implementation-specific and difficult to match in IronPython, or is proper Python but impossible to match for IronPython. For all such cases I would like to submit patches to the CPython repo, but I am new to this process. Should such case first be reported on bpo, python-dev, or just straight a github PR?Sometimes, by writing additional tests for IronPython we discover what seems as possible bugs in CPython. I was planning to submit reports for them on bpo, assuming this is the proper place to discuss them, but perhaps python-dev is a better place.> So fixing the tests to allow it either way sounds good.A github PR is on its way.

New changesetb6643dcfc26859f935e4b3a6a2a203e8ef5320e2 by Jason R. Coombs (Pavel Koneski) in branch 'master':bpo-36919: make test_source_encoding.test_issue2301 implementation-independent (#13639)https://github.com/python/cpython/commit/b6643dcfc26859f935e4b3a6a2a203e8ef5320e2

New changesetc2119399488a297275db7f0590cff957b6ce8a2e by Jason R. Coombs (Miss Islington (bot)) in branch '3.7':bpo-36919: make test_source_encoding.test_issue2301 implementation-independent (GH-13639) (GH-15953)https://github.com/python/cpython/commit/c2119399488a297275db7f0590cff957b6ce8a2e

New changeset42edfcfd129c7ac4842b9e0cd453bbe3ff006669 by Jason R. Coombs (Miss Islington (bot)) in branch '3.8':bpo-36919: make test_source_encoding.test_issue2301 implementation-independent (GH-13639) (GH-15952)https://github.com/python/cpython/commit/42edfcfd129c7ac4842b9e0cd453bbe3ff006669