Most changes to Pythonrequire a NEWS entry.

Please add it using theblurb_it web app or theblurb command-line tool.

All commit authors signed the Contributor License Agreement.

I was able to cobble my way through the C docs and write what I think is a reasonable attempt at a pure C dedent function (I forgot how fun -- albiet time consuming --- pointer logic can be).

To highlight some of the corner cases that need to be accounted for, this is the test case I'm using locally:

python -c "import subprocess# Use $ to note when a line will have all whitespacelines = '''         $  $    data = \"\"\"        this data has newlines above and below  $                            $    \"\"\"    if 1:         $        print(123)$    print(12345)    print(repr(data))'''.replace('$', '')subprocess.run(['./python', '-c', lines])"

I still haven't handled tabs, but I think my space logic is correct. I do need help vetting my C code and fixing the memory and security problems with it.

Delete all yourwchar_t stuff. It is error-prone and unnecessary.

Delete all your_unicode_dedent. It is lengthy. Doutf_8_bytes_dedent is much more concise and simpler.

You should act fast since 3.12 release window will soon close. No new feature after May 8.
https://peps.python.org/pep-0693/

Can you give me write access to your branch?

@sunmy2019 I gave you access to my cpython fork.

I got one thought:

textwrap.dedent remove space and tabs.
https://docs.python.org/3/library/textwrap.html#textwrap.dedent

textwrap.dedent(""" \t\t1   2""")'\n\t\t1\n  2'

It requires remembering the exact "space and tab prefix". Should we implement this?

It requires remembering the exact "space and tab prefix". Should we implement this?

Probably, but off the top of my head I'm not sure what the most elegant way to do it would be. I suppose instead of maintaining the tab and space counts, it would be sufficient to maintain the current shortest whitespace sequence, and then check how much of that sequence new lines match, shortening the sequence as necessary. I can give that a try.

On a different note, I'm sure that new features will want tests associated with them, but I'm not sure where the other "-c" tests live. Do you know where the best spot to put tests would be?

I got one thought:

textwrap.dedent remove space and tabs.

@Erotemic, take a look. I have implemented it with production quality atd336ac7.

Edit your#103998 (comment) to make it clear and concise, so that we can attract more reviewers.

On a different note, I'm sure that new features will want tests associated with them, but I'm not sure where the other "-c" tests live. Do you know where the best spot to put tests would be?

I guessLib/test/test_cmd_line.py

We need someone with write access to review this.

@vstinner as the recent maintainer of this file.
@hauntsaninja

@AA-Turner CI issues have been resolved.

Since this patch was last updated the "Core and Builtins" news section had spaces in its path name removed, so the file for this patch had to be moved to the new correct location.

The other issue was a c compiler warning, which was elevated to an error by CI policy. The usage of_PyUnicode_Dedent did not have an explicit include in the c file that used it. Adding the explicit include of pycore_unicodeobject.h addressed the problem.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phraseI have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Ah, I've deleted a comment by mistake. My comment was about the constructionPy_INCREF(x); return x; which can be replaced byreturn Py_NewRef(x);.

I have made the requested changes; please review again

Please update therefcount.dat file (don't remember if it's in Tools, Doc or somewhere else).

I overlooked this. I will check it later.

It's fine, this is just for internal knowledge