Repository navigation
Refactor PyUnicodeError internal C helpers #127787
Description
Activity
- changed the title
[-]Refactor `PyUnicodeError` internal C helpers[/-][+]gh-126004: Refactor `PyUnicodeError` internal C helpers[/+]on Dec 10, 2024 - changed the title
[-]gh-126004: Refactor `PyUnicodeError` internal C helpers[/-][+]Refactor `PyUnicodeError` internal C helpers[/+]on Dec 10, 2024 I think the gh-126004 issue can be used for the related refactoring. But I guess this one works as well.
IMO, there can be a
_PyUnicodeError_GetParamsto get all ofobject,size,startandendat the same time, and base the public functions on that.
Inunicodeobjectthe compiler could hopefully inline the function and elide the extra work, andcodecsusually needs all the values._PyUnicodeError_GetParams
Ah I missed this one. I can add it now (the interface is nice enough). You can comment on the PR which functions you'd like to unify even more.
EDIT: I've added this one and removed un-necessary functions. Now it looks much nicer!
- added a commit that references this issue
on Jan 3, 2025 I can now close this one and move back to fixing the codecs.
- added a commit that references this issue
on Jan 21, 2025
Feature or enhancement
Proposal:
Some helpers make the realization of #126004 a bit harder as we end up with many duplicated code. In order to make the related PRs and #127694 smoother, I suggest refactoring the following helpers:
get_unicodeandget_stringas a singleas_unicode_error_attribute.objectattribute and its size in one function, sayget_unicode_error_object_and_size. This is typically useful for unifyingPyUnicode{Encode,Decode,Translate}Error_GetObjectpublic functions can use a common implementationunicode_error_get_object_impl. Since this depends on the underlyingobjecttype, the implementation function would take a flag as a parameter to indicate whether it's a bytes or a string.PyUnicode{Encode,Decode}Error_GetEncodingpublic functions can use a common implementationunicode_error_get_encoding_impl. The encoding is always a string.PyUnicode{Encode,Decode,Translate}Error_{Get,Set}Reasonpublic functions can use a common implementationunicode_error_{get,set}_reason_impl. The reason is always a string.PyUnicode{Encode,Decode,Translate}_{Get,Set}{Start,End}public functions can use a common implementationunicode_error_{get,set}_{start,end}_impl. Since this depends on the underlyingobjecttype, the implementation function would take a flag as a parameter to indicate whether it's a bytes or a string.Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
#127674 (comment)
Linked PRs
PyUnicodeErrorObjectinternal interface #127789_PyUnicodeError_GetParams#128980