Repository navigation
Argument Clinic's [python input] blocks do not support /* in literal strings #128153
Closed as not planned
Description
Bug report
Bug description:
The following is not a valid Python input clinic but should be:
/*[python input]
print("/* this is a comment *\/")
[python start generated code]*/Note that the inner C comment should be *\/ because otherwise IDEs will consider the block comment to be closed resulting in syntax errors (for the C file). Another example is just:
/*[python input]
x = "/*"
[python start generated code]*/Both result in the following error (I've just added the AC directive in the first file I had opened):
$ python3 ./Tools/clinic/clinic.py --force --make --exclude Lib/test/clinic.test.c --srcdir .
Error in file 'Modules/sha1module.c' on line 270:
Nested block comment!
make: *** [Makefile:1055: clinic] Error 1For now the workaround is to break /* into multiple strings: x = "/" + "*" for instance.
CPython versions tested on:
CPython main branch
Operating systems tested on:
No response
Activity
[-] Argument Clinic's [python input] blocks do not support `/*` in literal strings[/-][+] Argument Clinic's `[python input]` blocks do not support `/*` in literal strings[/+]erlend-aasland commentedon Jan 3, 2025
Should it? This will generate a C compiler warning:
Would it not be better to use C++ style comments for these cases?
picnixz commentedon Jan 3, 2025
Oh I'm surprised about this. I'll need to check on my side if adding
\/*would be fine or not for the C compiler. Though, I think it would still not be fine for clinic since the substring/*is present.I'm going to sleep now so I'll need to think about feature this is a bug or not more tomorrow.
I think I can use
//comments but it was mostly a question of style (I usually reserve/*for external documentation (like a Doxygen thing) and//for internal documentation). But I can make an exception for clinic (see https://github.com/python/cpython/pull/125011/files#diff-7bb6f3c67c8fec78f79fc7f5f74f26aa808d97c5e2ce5a538292056f8eb46b8aR150 for its usage).erlend-aasland commentedon Jan 3, 2025
For the linked use case,
//is definitely fine. Moreover, we don't use Doxygen, and there are no style recommendations regarding old-style or new-style C comments. You actually can't make an exception; there is no rule :)Suggesting to rebrand this issue as a feature request, and I'm aligned to reject that feature.
picnixz commentedon Jan 3, 2025
I mean an exception to my own guidelines for me :')
I'm fine with a rejection since the workaround isn't really an issue (the only reason why
/*is needed is if you want to generate a multi-line macro with comments inside since//are not allowed in this case AFAIK). Since I don't have a use-case for now, let's close it for now.