For informational purposes: https://devguide.python.org/versions/

The latest version of setuptools which supports python 2.7 is setuptools 44.1.1 [1], the latest version of pip which supports python 2.7 and 3.5 is pip 20.3.4 [2].

[1] https://setuptools.pypa.io/en/latest/history.html#v45-0-0
[2] https://pip.pypa.io/en/stable/news/#v21-0

If we decide to drop python 2, we can maintain a legacy branch 0.2.x for python 2, and backport bug fixes only (including unicode table updates). The question is: what can we get from dropping python 2 and 3.5 (or even 3.6, 3.7)? Typing on python 2 is difficult, but I don't think #71 is an unsolvable problem, maybe it just need some more investigation.

If we drop python 2 only (requires python>=3.5):

• we can get rid of all of str unicode confusion
• lru_cache and typing are available in stdlib
• syntax for function annotations (PEP 3107): def wcwidth(wc: str, unicode_version: str = 'auto') -> int: ...
• use python -Im instead of python -m in CI
• the latest version of mypy which supports --python-version 3.5 is mypy 1.5 [3][4]

[3] https://mypy-lang.blogspot.com/2023/10/mypy-16-released.html
[4] python/mypy@14743a1

If we drop python<=3.5 (requires python>=3.6):

• PEP 526: syntax for variable annotations

If we drop python<=3.6 (requires python>=3.7):

• from __future__ import annotaions so that we can use newer syntax such as tuple[int, ...] and str | None
• unpin virtualenv<20.22.0 and use the latest virtualenv [5]
• we can use the latest version of mypy

[5] https://tox.wiki/en/4.11.3/faq.html#testing-end-of-life-python-versions

IMO currently it seems not worth to maintain 2 different branches. We can reconsider this if #71 is proven unsolvable unless dropping python 2, or we encounter more problems in the future.

I agree with everything you say. I don't have much inclination to do the work to remove python 2 support myself, I would only be inclined to remove it when I am unable to reasonably test it or continue to support it.

On 'What do we get?',

there is little to gain, only to drop the maintenance burden for tasks like #71. It is minor burden for the changes I expect to make, even in the ~30 hours of work I recently dedicated, only ~1 hours work was required to ensure python 2 compatibility.

We have previously discussed the idea of Cython or C-compiled assistance for performance (I will open an issue shortly), and, continuing to support python 2 and 3.5, and, the operating systems and build tools that would accompany it, might be too burdensome to maintain at that time, but I would only worry about it then.

And for typing on the whole, #71, I am in no hurry to drop support for ~1 million downloads/month of "users", for the ~10 developer who might benefit from types, and even then I believe there is little to gain there as this library API is basic, obvious and the types are in the docstrings, it's hardly worth the attention!

On 'it seems not worth to maintain 2 different branches'

I propose to drop python 2/mark a release as "final python 2 release". With #91 and #97 now released for python 2.7, and, 'ucs-detect' tool and results mostly complete, and over time with open number of issues low, I can say with high confidence that wcwidth seems to be >99% accurate for all versions of unicode up to 15.0

And, as for Unicode updates, version 15 is able to accurately write a great majority of the world's languages. I expect only very minority and ancient languages, symbols/emojis, and rare punctuation additions in future releases.

And, that in the case of supporting legacy software that is stuck on python 2.7, I see little need to continue to support python 2.7 for Unicode versions 16+. They would not likely also be using the latest 2023 releases of terminal emulators, and also be in need of viewing characters exclusive to future releases like Unicode 16.

The pypi stats don't give great insights on what python versions are pulling which versions AFAICT, so I ran a quick query on the public pypi dataset for the past 30 days

SELECT REGEXP_EXTRACT(details.python, r"[0-9]+\.[0-9]+") AS python_version, file.version, COUNT(*) AS num_downloads FROM `bigquery-public-data.pypi.file_downloads` WHERE file.project = 'wcwidth' AND 
  DATE(timestamp) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY) AND CURRENT_DATE()
GROUP BY `python_version`, file.version
ORDER BY `python_version`, file.version

Please see #117 to drop 2.7 and 3.5.

And for typing on the whole, #71, I am in no hurry to drop support for ~1 million downloads/month of "users", for the ~10 developer who might benefit from types, and even then I believe there is little to gain there as this library API is basic, obvious and the types are in the docstrings, it's hardly worth the attention!

You can add me as number 11 who would like types :) I also maintain PrettyTable which accounts for about 10 million downloads/month of wcwidth, around 20%.

And for typing on the whole, #71, I am in no hurry to drop support for ~1 million downloads/month of "users", for the ~10 developer who might benefit from types, and even then I believe there is little to gain there as this library API is basic, obvious and the types are in the docstrings, it's hardly worth the attention!

I agree with this. But the problem is, adding types doesn't need py2 support to be dropped. If api is basic and stable, we don't even need to change pyi.