Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove narrow build detection #1660

Merged
merged 2 commits into from Jan 12, 2022

Conversation

aucampia
Copy link
Member

Before Python 3.3 and PEP 393
(which came in with Python 3.3) there was a distinction between narrow
and wide python builds.

However this is no longer the situation, and chr(0x10FFFF) should not
raise ValueError on any python build.

From PEP 393:

The Unicode string type is changed to support multiple internal
representations, depending on the character with the largest Unicode
ordinal (1, 2, or 4 bytes). This will allow a space-efficient
representation in common cases, but give access to full UCS-4 on all
systems. For compatibility with existing APIs, several representations
may exist in parallel; over time, this compatibility should be phased
out. The distinction between narrow and wide Unicode builds is dropped.

From Python 3.7 docs for Unicode Objects and Codecs
docs regarding Py_UNICODE:

Changed in version 3.3: In previous versions, this was a 16-bit type
or a 32-bit type depending on whether you selected a “narrow” or “wide”
Unicode version of Python at build time.

Before Python 3.3 and [PEP 393](https://www.python.org/dev/peps/pep-0393/)
(which came in with Python 3.3) there was a distinction between narrow
and wide python builds.

However this is no longer the situation, and `chr(0x10FFFF)` should not
raise `ValueError` on any python build.

From [PEP 393](https://www.python.org/dev/peps/pep-0393/):

> The Unicode string type is changed to support multiple internal
> representations, depending on the character with the largest Unicode
> ordinal (1, 2, or 4 bytes). This will allow a space-efficient
> representation in common cases, but give access to full UCS-4 on all
> systems. For compatibility with existing APIs, several representations
> may exist in parallel; over time, this compatibility should be phased
> out. The distinction between narrow and wide Unicode builds is dropped.

From [Python 3.7 docs for Unicode Objects and Codecs](https://docs.python.org/3.7/c-api/unicode.html)
docs regarding `Py_UNICODE`:

> Changed in version 3.3: In previous versions, this was a 16-bit type
> or a 32-bit type depending on whether you selected a “narrow” or “wide”
> Unicode version of Python at build time.
@aucampia
Copy link
Member Author

Noticed while working on fix for #1655

Deleting this test to complete removal of narrow/wide distinction
@nicholascar
Copy link
Member

Just removed a test for narrow builds that I remembered was there

@nicholascar nicholascar merged commit a6c5169 into RDFLib:master Jan 12, 2022
@aucampia aucampia deleted the iwana-20220110T2208-remove_narrow branch April 9, 2022 14:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants