[issue40243] Unicode 3.2 numeric uses decimal_changed instead of numeric_changed
Change by William Meehan : -- components: Unicode nosy: ezio.melotti, vstinner, wmeehan priority: normal severity: normal status: open title: Unicode 3.2 numeric uses decimal_changed instead of numeric_changed type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40243] Unicode 3.2 numeric uses decimal_changed instead of numeric_changed
Change by William Meehan : -- keywords: +patch pull_requests: +18812 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19457 ___ Python tracker <https://bugs.python.org/issue40243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41524] PyOS_mystricmp advances pointers too far
New submission from William Meehan :
The existing implementation of PyOS_mystricmp increments both pointers as long
as the first string hasn't reached the end yet. If the second string ends
first, then we increment past the null byte. If there is a difference in the
middle of the two strings, then the result actually compares the following pair
of letters.
e.g.
PyOS_mystricmp("a", "\0") => 0 (should be positive)
PyOS_mystricmp("foo", "fro") => 0 (should be negative)
Similarly, PyOS_mystrnicmp increments the pointers in a condition before
breaking out of the loop. It's possible to increment the first pointer without
incrementing the second, and the result is the character past the null byte.
e.g.
PyOS_mystrnicmp("\0a", "\0b", 2) => 97 (should be negative)
--
components: C API
messages: 375203
nosy: wmeehan
priority: normal
severity: normal
status: open
title: PyOS_mystricmp advances pointers too far
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python
3.9
___
Python tracker
<https://bugs.python.org/issue41524>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41524] PyOS_mystricmp advances pointers too far
Change by William Meehan : -- keywords: +patch pull_requests: +20972 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/21845 ___ Python tracker <https://bugs.python.org/issue41524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
Change by William Meehan : -- components: Tests nosy: wmeehan priority: normal severity: normal status: open title: Other Python implementations may not expose the module name in datetime type names versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
New submission from William Meehan : This just requires some changes to test_datetime and test_hash -- ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
Change by William Meehan : -- keywords: +patch pull_requests: +22237 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23345 ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42390] Other Python implementations may not expose the module name in datetime type names
William Meehan added the comment: For Python implementations that change the underlying object structure, it's not necessarily possible to recreate the `tp_name` that would be exposed in CPython. The `datetime` ends up in `__module__`, while only the type name ends up in `__name__`. There's no way to tell that the value in `__module__` actually came from `tp_name` in the first place. -- ___ Python tracker <https://bugs.python.org/issue42390> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
