You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
#113745 added a new built-in exception IncompleteInputError, but it is not mentioned anywhere in the docs (except in the auto-generated list of classes) or in the What's New. It should be documented. cc @pablogsal
I don't want to document this as this is an implementation detail of the parser specially tailored for the codeop module. It is only raised when a very specific undocumented flag is passed to the parser to support better what the codeop module needs to do and I don't think we want users to depend on it.
Possibly the new exception should be given a dunder name (since dunder names are reserved for the language), or placed in some private extension module (maybe _ast?).
It's a builtin though. If we don't want this to be public, we shouldn't have put it in the builtins.
That's a side effect of being a subclass of SyntaxError that's available via the normal subclass in exceptions.c mechanism in a way that generates directly a type that we can use in the parser, unfortunately. Adding this to a module is much more complicated due to a bootstrapping problem with the parser (I need to double check if this is 100% the case so take this with a pinch of salt)
Bad news: I dedicated some time to investigate and seems prepending the symbol with an underscore fails in macOS because prepending the symbol with an underscore triggers some linkage failure (doing any other alterations to the symbol name does not). Also, exceptions cannot be easily declared outside the Objects/exceptions.c module and even if they can there is a bootstrapping problem with the parser. We can proceed in two ways:
Remove the exception, make the parser raise some weird exception and somehow parse the message (very ugly and error prone).
Document the exception and say is an implementation detail.
Document the exception.
Somehow investigate if there is a way to override this problem with linkage
Undefined symbols for architecture arm64:
"__PyExc_IncompleteInputError", referenced from:
__PyPegen_run_parser in pegen.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Programs/_freeze_module] Error 1
We only want the Python-visible name to have an underscore (or two) though, the C name can stay. So I think you could manually expand the MiddlingExtendsException macro and use a different name for the C type name and the Python-visible __name__.
We only want the Python-visible name to have an underscore (or two) though, the C name can stay. So I think you could manually expand the MiddlingExtendsException macro and use a different name for the C type name and the Python-visible __name__.
I was a bit reluctant to add a new macro just for this but it seems that there is no much around this unfortunately
Activity
pablogsal commentedon May 24, 2024
I don't want to document this as this is an implementation detail of the parser specially tailored for the codeop module. It is only raised when a very specific undocumented flag is passed to the parser to support better what the codeop module needs to do and I don't think we want users to depend on it.
JelleZijlstra commentedon May 24, 2024
It's a builtin though. If we don't want this to be public, we shouldn't have put it in the builtins.
JelleZijlstra commentedon May 24, 2024
Possibly the new exception should be given a dunder name (since dunder names are reserved for the language), or placed in some private extension module (maybe
_ast?).pablogsal commentedon May 25, 2024
That's a side effect of being a subclass of SyntaxError that's available via the normal subclass in
exceptions.cmechanism in a way that generates directly a type that we can use in the parser, unfortunately. Adding this to a module is much more complicated due to a bootstrapping problem with the parser (I need to double check if this is 100% the case so take this with a pinch of salt)pablogsal commentedon May 25, 2024
We can try to prepend a underscore to the name for sure.
I can try to investigate if there is an easy way to move it to some other hidden place when used via Python as well but IIRC it's a bit complex
pablogsal commentedon May 25, 2024
Bad news: I dedicated some time to investigate and seems prepending the symbol with an underscore fails in macOS because prepending the symbol with an underscore triggers some linkage failure (doing any other alterations to the symbol name does not). Also, exceptions cannot be easily declared outside the
Objects/exceptions.cmodule and even if they can there is a bootstrapping problem with the parser. We can proceed in two ways:pablogsal commentedon May 25, 2024
I may be possible that I am missing something obvious, but this diff:
fails with:
JelleZijlstra commentedon May 27, 2024
We only want the Python-visible name to have an underscore (or two) though, the C name can stay. So I think you could manually expand the
MiddlingExtendsExceptionmacro and use a different name for the C type name and the Python-visible__name__.pablogsal commentedon May 28, 2024
I was a bit reluctant to add a new macro just for this but it seems that there is no much around this unfortunately
12 remaining items
pythongh-119521: Remove _IncompleteInputError from the docs (pythonGH…
[3.13] gh-119521: Remove _IncompleteInputError from the docs (GH-120993…
pythongh-119521: Rename IncompleteInputError to _IncompleteInputError…
pythongh-119521: Use `PyAPI_DATA`, not `extern`, for `_PyExc_Incomple…
pythongh-119521: Remove _IncompleteInputError from the docs (pythonGH…
Looks like the Py3.13 builtin 'IncompleteInputError' was renamed to '…
pythongh-119521: Rename IncompleteInputError to _IncompleteInputError…
pythongh-119521: Use `PyAPI_DATA`, not `extern`, for `_PyExc_Incomple…
pythongh-119521: Remove _IncompleteInputError from the docs (pythonGH…
pythongh-119521: Rename IncompleteInputError to _IncompleteInputError…
pythongh-119521: Use `PyAPI_DATA`, not `extern`, for `_PyExc_Incomple…
pythongh-119521: Remove _IncompleteInputError from the docs (pythonGH…
pypi-cython: Autospec creation for update from version 3.0.12 to vers…