I am not sure about the name. On one hand, it looks correct and I do not have anything better, on other hand, it can be confused with the use case for BlockingIOError. In future we can see misuse of this error in cases not related to parsing Python sources. Not sure if it's something to worry about.

I don't think we should worry about it because it's not user facing (at least for now). It's used internally in a special mode of the parser that's also not user facing. And in the rare case where a user encounters it it's relatively easy to identify why is appearing.

Let's not add it to the stable ABI, then?

Let's not add it to the stable ABI, then?

Sorry @encukou but seems that the auto-land landed it before I could tackle your comment. Do you want to remove it from the stable ABI? The name is public in any case so it would be weird if is not there but you can invoke it from builtins

If it is used internally in a special mode of the parser, it could be not added to buildins. But I do not see how this mode is special. It does not use any magic flags or private arguments. I expect it to be used in many third-party REPL implementations. And maybe even in the C code. So it is okay to make it as public as other SyntaxError subclasses.

I don't think we should worry about [the name] because it's not user facing (at least for now).

Adding it to the public C API (and especially to the stable ABI) means that it is user facing, and now is the time to worry about the name.
If there is a chance we'll find a better way, and we'll need to deprecate/remove this, it shouldn't go it the stable ABI.

TBH, the name is fine with me. IncompleteSourceError might be more descriptive.