Pasting zero-width characters into PyREPL results in incorrect cursor position

Bug report

Bug description:

To reproduce

Tested with Python 3.14 rc3 on Linux

Open the new REPL
Paste: ééééé

The paste-able string above is five letter 'e's each followed by \u0301. To create it use:

print('e\u0301' * 5)

The \u0301 is a combining mark with zero-width display length

Current behavior

The cursor position is five spaces after the pasted string

Expected behavior

The cursor position is immediately after the pasted string

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

The root cause seems to be related to pyrepl wlen miscalculating the length of the zero-width combining mark

wlen('e\u0301') is 2 instead of 1

Possibly related: #130273

>>> ééééé/0
Traceback (most recent call last):
  File "<python-input-6>", line 1, in <module>
    ééééé/0
    ~~~~~~~~~~^~
ZeroDivisionError: division by zero

@StanFromIreland

@StanFromIreland It does look like traceback has a similar mishandling of zero-width characters in _display_width

something like
seems width is wrong here

é
ȩ

@grayjk

I create a draft patch maybe can fix this can you help test?
cc @grayjk

Also affects Python 3.13

gh-139246: zero-width word paste can be wrong in default repl (GH-139254

pythongh-139246: zero-width word paste can be wrong in default repl (p…

[3.13] pythongh-139246: zero-width word paste can be wrong in default…

[3.14] gh-139246: zero-width word paste can be wrong in default repl (G…

[3.13] gh-139246: zero-width word paste can be wrong in default repl (G…

Thank you for the fix!
Should we keep this open for consolidating this and the calculations for tracebacks?

Thank you for the fix! Should we keep this open for consolidating this and the calculations for tracebacks?

yes I think keep it open is better since there's a lot of case for the wcwidth

Hangul Jamo (https://www.unicode.org/faq/korean#3) also has zero width conjoining characters: https://wcwidth.readthedocs.io/en/latest/specs.html#width-of-0

An example is:

print("\u1100\u1161")

which displays:

가

The pyrepl wlen function in 3.15.0a2 returns 3 for this character. The length should be 2

Since the wlen return is incorrect, pasting the character results in an incorrect cursor position

가

This is the same behavior in basic repl and other repl I think its fine here?

가

It somehow looks ugly in my 3.14.0 REPL. (I think it's the OS problem, it looks fine on Linux)
And yes, we should calc its wlen as 2.

@grayjk

Do you think we should improve wlen and str_width based on wcwidth, or we should only fix when there's incorrect behavior occurs? @grayjk

pythongh-139246: zero-width word paste can be wrong in default repl (p…

We get an incorrect number of carets for 가, and when trying delete it, on the second backspace it takes too much:

>>> 가/0
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    가/0
    ^^^
NameError: name '가' is not defined

And, when trying delete it, on the second backspace it takes too much:

>>

@StanFromIreland

@StanFromIreland what Python version?

I tested in 3.15.0 beta 1 with Putty and it worked (i.e. displayed 2 carets).

The backspace problem is tracked in issue #142162

Navigation Menu

Repository navigation

Pasting zero-width characters into PyREPL results in incorrect cursor position #139246

Bug report

Bug description:

To reproduce

Current behavior

Expected behavior

CPython versions tested on:

Operating systems tested on:

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Pasting zero-width characters into PyREPL results in incorrect cursor position #139246

Description

Bug report

Bug description:

To reproduce

Current behavior

Expected behavior

CPython versions tested on:

Operating systems tested on:

Linked PRs

Activity

grayjk commented on Sep 22, 2025

StanFromIreland commented on Sep 22, 2025

grayjk commented on Sep 22, 2025

yihong0618 commented on Sep 23, 2025

yihong0618 commented on Sep 23, 2025

grayjk commented on Sep 24, 2025

encukou commented on Nov 7, 2025

yihong0618 commented on Nov 7, 2025

grayjk commented on Dec 1, 2025

yihong0618 commented on Dec 3, 2025

typenoob commented on Dec 3, 2025

typenoob commented on Dec 3, 2025

StanFromIreland commented on May 9, 2026

StanFromIreland commented on May 9, 2026

StanFromIreland commented on May 9, 2026

grayjk commented on May 11, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions