[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Changes by Donald Stufft : -- pull_requests: +1024 ___ Python tracker ___ ___

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Changes by Serhiy Storchaka : -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Roundup Robot added the comment: New changeset 3addf93f4111 by Serhiy Storchaka in branch 'default': Issue #28774: Simplified encoding a str result of an error handler in ASCII https://hg.python.org/cpython/rev/3addf93f4111 -- ___ Python tracker

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Serhiy Storchaka added the comment: Congratulations, Xiang! -- ___ Python tracker ___ ___ Python-bugs-list

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Xiang Zhang added the comment: Thanks Serhiy and Victor. Finished my first commit. :-) Now assign back to Serhiy and pos2 LGTM. -- assignee: xiang.zhang -> serhiy.storchaka ___ Python tracker

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Roundup Robot added the comment: New changeset 3d660ed2a60e by Xiang Zhang in branch 'default': Issue #28774: Fix start/end pos in unicode_encode_ucs1(). https://hg.python.org/cpython/rev/3d660ed2a60e -- nosy: +python-dev ___ Python tracker

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

STINNER Victor added the comment: > No need to backport it to 3.6 (if I didn't miss something). Sorry, I misunderstood the issue. It's an enhancement, so for 3.7 only. Right, 3.6 is now almost frozen, only major bug fixes blocking the release are accepted now (in short). Regular bugfixes

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Serhiy Storchaka added the comment: This is not a bug itself. It seems to me that at worst case the current code is less efficient with non-standard error handler than it can be. I would commit the path to the 3.6 branch before beta 4 as it is nice and simple additional to already added

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

STINNER Victor added the comment: > LGTM. But it is too late for beta 4. I'll commit the patch either after > releasing 3.6.0 or in the 3.7 branch only. Right now, I suggest to only commit into 3.7. Such minor bug can wait for Python 3.6.1. > And while we are here I noticed that handling

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Serhiy Storchaka added the comment: LGTM. But it is too late for beta 4. I'll commit the patch either after releasing 3.6.0 or in the 3.7 branch only. And while we are here I noticed that handling non-ASCII replacement string could be simpler. -- Added file:

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Changes by STINNER Victor : -- versions: -Python 3.6 ___ Python tracker ___ ___

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

STINNER Victor added the comment: If I understood correctly, the patch fix the ASCII encoder to handle correctly error handlers which return non-ASCII text replacement strings. Right? I am not aware of such error handler, so I guess that it's a more a theorical fix? I really hate the code

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

Changes by Serhiy Storchaka : -- assignee: -> serhiy.storchaka priority: normal -> low ___ Python tracker ___

[issue28774] Better start and end position for unicodeerror in unicode_encode_ucs1

New submission from Xiang Zhang: unicode_encode_ucs1 now recognizes as many characters as it can one time instead of one character a time. But the unicodeerror positions still only count 1(the second time). A similar problem reported in #28561. -- components: Interpreter Core files: