BUG: Print alignement problem with some unicode characters

[mhooreman]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

import pandas as pd
print(pd.DataFrame({'a': 'FooXXXXX,BarXXXXX,BazXXXXX,💾,🤓🤘'.split(','), 'b': 1}))

Issue Description

The example prints the following output:

          a  b
0  FooXXXXX  1
1  BarXXXXX  1
2  BazXXXXX  1
3         💾  1
4        🤓🤘  1

It seems that some unicode characters are shifting the position to the right.
I have tried with different ranges (number of used bytes), and I can't find where the issue comes from.

Expected Behavior

          a  b
0  FooXXXXX  1
1  BarXXXXX  1
2  BazXXXXX  1
3        💾  1
4      🤓🤘  1

(well, there's also an alignement problem on github, but the "1" shall be aligned)

Installed Versions

INSTALLED VERSIONS
------------------
commit                : 0691c5cf90477d3503834d983f69350f250a6ff7
python                : 3.13.2
python-bits           : 64
OS                    : Darwin
OS-release            : 22.6.0
Version               : Darwin Kernel Version 22.6.0: Thu Apr 24 20:25:14 PDT 2025; root:xnu-8796.141.3.712.2~1/RELEASE_X86_64
machine               : x86_64
processor             : i386
byteorder             : little
LC_ALL                : None
LANG                  : en_US.UTF-8
LOCALE                : en_US.UTF-8

pandas                : 2.2.3
numpy                 : 2.2.6
pytz                  : 2025.2
dateutil              : 2.9.0.post0
pip                   : None
Cython                : None
sphinx                : None
IPython               : None
adbc-driver-postgresql: None
adbc-driver-sqlite    : None
bs4                   : None
blosc                 : None
bottleneck            : None
dataframe-api-compat  : None
fastparquet           : None
fsspec                : None
html5lib              : None
hypothesis            : None
gcsfs                 : None
jinja2                : None
lxml.etree            : None
matplotlib            : None
numba                 : None
numexpr               : None
odfpy                 : None
openpyxl              : 3.1.5
pandas_gbq            : None
psycopg2              : None
pymysql               : None
pyarrow               : None
pyreadstat            : None
pytest                : None
python-calamine       : None
pyxlsb                : None
s3fs                  : None
scipy                 : None
sqlalchemy            : None
tables                : None
tabulate              : None
xarray                : None
xlrd                  : None
xlsxwriter            : None
zstandard             : None
tzdata                : 2025.2
qtpy                  : None
pyqt5                 : None

[iabhi4]

The misalignment seems to be happening because pandas calculates column widths using len() or east_asian_width(), which doesn’t really work well for emojis or other wide Unicode characters, they take up more space visually than you'd expect.

I tried patching this locally by using wcwidth.wcswidth() instead of len() to get the actual terminal width of characters. I also had to override the justify() method to pad strings based on how wide they look in the terminal, not how many characters they have since .ljust() and .rjust() don’t consider visual width.

With those changes, the alignment now works as expected even with emojis. I’d love to open a PR for this, just wanted to check first if maintainers would be okay with using wcwidth, or if you'd prefer a fallback or vendored version instead

[mhooreman]

Thanks a lot @iabhi4 !

I didn't knew about that library, it sounds very useful. I'm just curious about the amount of code used by this solution and the extensive auto generated modules: wouldn't it affect too mush the performance ? Can't it be simpler ?

No criticism, just questioning.

[iabhi4]

I didn't knew about that library, it sounds very useful. I'm just curious about the amount of code used by this solution and the extensive auto generated modules: wouldn't it affect too mush the performance ? Can't it be simpler ?

Totally fair to ask, I was also a bit unsure at first about adding more complexity, especially with an external library. But wcwidth is actually pretty lightweight, it’s just a small pure Python module that handles tricky Unicode cases like emojis and wide characters that len() or east_asian_width() can’t deal with properly.

That said, you’re right about performance, calling wcswidth() for every string does add overhead. To keep things efficient, I’ve been experimenting with a fallback strategy: using len() for simple ASCII strings (which covers most real-world cases), and only using wcswidth() when there’s something unusual, like an emoji. I’m also trying out caching to avoid recalculating widths for repeated values.

Really appreciate you raising this, I’m totally open to feedback and happy to explore simpler solutions if there's a better way!

[mhooreman]

Thanks a lot everybody.

I don't know a lot about Unicode, but I'm pretty sure that rules computation can be implemented without adding another dependance. It could also be feasible in C or cython to keep good performances.

While investigating, I've found an interesting explanation, out of a Rust lib.

Now, the one billion dollars question: is it the good place to fix it in pandas, or would it be better to be associated with python? ... And the sub question: what is the reason why python has implemented len that way and what could be the side effects on a change?