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

Changes by Donald Stufft : -- pull_requests: +1024 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[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 mailing list Unsubscribe:

[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 shoul

[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 optimi

[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 non

[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: http://bugs.python.org/fi

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

Changes by STINNER Victor : -- versions: -Python 3.6 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[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 (in

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

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

[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: un