Skip to content

gh-62436: Adjust str.isspace to use Unicode's White_Space property. - #16254

Open
gnprice wants to merge 4 commits into
python:mainfrom
gnprice:pr-whitespace
Open

gnprice wants to merge 4 commits into
python:mainfrom
gnprice:pr-whitespace

Conversation

@gnprice

@gnprice gnprice commented Sep 18, 2019 •

Copy link
Copy Markdown
Contributor

When Unicode support was first added to Python, there was no Unicode
property identifying whitespace, so we approximated it by putting
together a couple of other properties.

Now there is a White_Space property, so let's use it.

Happily, the difference from our original approximation is only in the
four rare control characters 001C..001F.

As a bonus, isspace now joins all similar methods in giving exactly
matching results for ASCII characters represented as str or as
bytes. Add a test for that nice property.

https://bugs.python.org/issue18236

When Unicode support was first added to Python, there was no Unicode
property identifying whitespace, so we approximated it by putting
together a couple of other properties.

Now there is a White_Space property, so let's use it.

Happily, the difference from our original approximation is only in the
four rare control characters 001C..001F.

As a bonus, `isspace` now joins all similar methods in giving exactly
matching results for ASCII characters represented as `str` or as
`bytes`.  Add a test for that nice property.

@Numerlor Numerlor left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran into an issue with this when I noticed int's stripping is different to str's, so it's nice to see that there's already a PR for a fix.

The introduced changes seem good to my eye that's not entirely familiar with the codebase, apart from the outdated version notices.

I've also noticed that the added docstrings to test_unicode are using single quote marks while others are using double quotes so changing that to be consistent would be nice

Comment thread Lib/test/test_str.py
Comment on lines +640 to +642
((bidirectional in ('WS', 'B', 'S')
or category == 'Zs')
and codepoint not in range(0x1c, 0x20)))

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this guaranteed to hold in future unicode versions? i.e. should it be tested on the string method if it's only testing the unicode database parsing and generation?

@github-actions

github-actions Bot commented Apr 7, 2026

Copy link
Copy Markdown

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions Bot added the stale Stale PR or inactive for long period of time. label Apr 7, 2026
@serhiy-storchaka serhiy-storchaka changed the title bpo-18236: Adjust str.isspace to use Unicode's White_Space property. gh-62436: Adjust str.isspace to use Unicode's White_Space property. Aug 12, 2026
@github-actions github-actions Bot removed the stale Stale PR or inactive for long period of time. label Aug 14, 2026
ambv added 2 commits October 23, 2026 00:28
Resolve conflicts by taking upstream versions of the regenerated
Objects/unicodetype_db.h and test checksum, and by adapting the PropList
parsing hunk to the current makeunicodedata.py structure.

Co-authored-by: Muse Code (Meta Muse Spark)
Regenerate Objects/unicodetype_db.h at Unicode 18.0.0 with the White_Space
property (25 whitespace code points; U+001C..U+001F no longer whitespace).
Retarget the docs versionchanged and test notes from 3.9 to 3.16, rename the
NEWS entry to the current gh-issue convention, and update the unicodedata
method checksums for the intended behavior change.

Co-authored-by: Muse Code (Meta Muse Spark)
@read-the-docs-community

read-the-docs-community Bot commented Oct 22, 2026 •

Copy link
Copy Markdown

Documentation build overview

📚 cpython-previews | 🛠️ Build #35339572 | 📁 Comparing 41a18d4 against main (c6661bd)

  🔍 Preview build  

5 files changed · ± 5 modified

± Modified

Required by the blurb-no-space-core-and-builtins lint hook.

Co-authored-by: Muse Code (Meta Muse Spark)
@ambv

ambv commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

This needs a decision since the behavior change is wider than the docs and NEWS say: everything built on Py_UNICODE_ISSPACE changes behaviour, and that includes 'a\x1fb\x1ec'.split(), '\x1cabc\x1d'.strip(), re.match(r'\s', '\x1f'), or Decimal('\x1c1\x1c'). All those work right now, but will change after the PR lands, with no deprecation and a silent behavioural change.

We'd also have to drop U+001C–U+001E from splitlines() in a separate sister change.

@ambv

ambv commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

@malemburg, what do you think? Those characters are used as delimiters in real-world data like RFC 7464 JSON text sequences, GS1 barcoes, MARC 21 library records, HL7 MLLP framing, probably more.

Even if we add a "Porting to 3.16" section and explain the difference, silent breakage of existing software is a real risk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants