GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Refactor `PyUnicodeError` internal C helpers · Issue #127787 · python/cpython

Refactor PyUnicodeError internal C helpers #127787

New issue
Copy link
New issue
Copy link
Closed
Closed
Refactor PyUnicodeError internal C helpers#127787
Copy link
Assignees
picnixz
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancementA feature request or enhancement

Description

@picnixz
picnixz
opened on Dec 10, 2024
Issue body actions

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:

  • Unify get_unicode and get_string as a single as_unicode_error_attribute.
  • Allow to retrieve the underlying object attribute and its size in one function, say get_unicode_error_object_and_size. This is typically useful for unifying
  • The PyUnicode{Encode,Decode,Translate}Error_GetObject public functions can use a common implementation unicode_error_get_object_impl. Since this depends on the underlying object type, the implementation function would take a flag as a parameter to indicate whether it's a bytes or a string.
  • All PyUnicode{Encode,Decode}Error_GetEncoding public functions can use a common implementation unicode_error_get_encoding_impl. The encoding is always a string.
  • All PyUnicode{Encode,Decode,Translate}Error_{Get,Set}Reason public functions can use a common implementation unicode_error_{get,set}_reason_impl. The reason is always a string.
  • All PyUnicode{Encode,Decode,Translate}_{Get,Set}{Start,End} public functions can use a common implementation unicode_error_{get,set}_{start,end}_impl. Since this depends on the underlying object type, 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

  • gh-127787: refactor helpers for PyUnicodeErrorObject internal interface #127789
  • gh-127787: Move _PyUnicodeError_GetParams() to the internal C API #128803
  • gh-127787: allow to retrieved the clipped slice length in _PyUnicodeError_GetParams #128980
Reacted by Erlend E. Aasland

Activity

  1. picnixz
    added
    type-featureA feature request or enhancementA feature request or enhancement
    interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)
    on Dec 10, 2024
  2. picnixz
    self-assigned this
    on Dec 10, 2024
  3. encukou
    changed the title [-]Refactor `PyUnicodeError` internal C helpers[/-] [+]gh-126004: Refactor `PyUnicodeError` internal C helpers[/+] on Dec 10, 2024
  4. encukou
    changed the title [-]gh-126004: Refactor `PyUnicodeError` internal C helpers[/-] [+]Refactor `PyUnicodeError` internal C helpers[/+] on Dec 10, 2024
  5. encukou commented on Dec 10, 2024

    @encukou
    encukou
    on Dec 10, 2024
    Member
    More actions

    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_GetParams to get all of object, size, start and end at the same time, and base the public functions on that.
    In unicodeobject the compiler could hopefully inline the function and elide the extra work, and codecs usually needs all the values.

  6. picnixz commented on Dec 10, 2024

    @picnixz
    picnixz
    on Dec 10, 2024
    MemberAuthor
    More actions

    _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!

  7. encukou
    added a commit that references this issue on Jan 3, 2025

    gh-127787: refactor helpers for `PyUnicodeErrorObject` internal inter…

    fa985be
  8. picnixz commented on Jan 3, 2025

    @picnixz
    picnixz
    on Jan 3, 2025
    MemberAuthor
    More actions

    I can now close this one and move back to fixing the codecs.

  9. picnixz
    closed this as completedon Jan 3, 2025
  10. WolframAlph
    added a commit that references this issue on Jan 4, 2025

    pythongh-127787: refactor helpers for `PyUnicodeErrorObject` internal…

    b5bb8cc
  11. srinivasreddy
    added a commit that references this issue on Jan 8, 2025

    pythongh-127787: refactor helpers for `PyUnicodeErrorObject` internal…

    02e0f80
  12. vstinner
    added 3 commits that reference this issue on Jan 13, 2025

    pythongh-127787: Move _PyUnicodeError_GetParams() to the internal C API

    0430dc7

    pythongh-127787: Move _PyUnicodeError_GetParams() to the internal C API

    fb13919

    gh-127787: Move _PyUnicodeError_GetParams() to the internal C API (#1…

    24a8d92
  13. encukou
    added a commit that references this issue on Jan 21, 2025

    gh-127787: allow retrieving the clipped slice length in `_PyUnicodeEr…

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

Metadata

Metadata

Assignees

  • @picnixz
    picnixz

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)(Objects, Python, Grammar, and Parser dirs)type-featureA feature request or enhancementA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.