search

jquast / wcwidth

Python library that measures the width of unicode strings rendered to a terminal
Other
392 stars 58 forks source link

Remove python2 compat codes, introduce dataclasses and type hints for `bin/update-tables.py` #58

Closed GalaxySnail closed 1 year ago

lgtm-com[bot] commented 2 years ago

This pull request introduces 1 alert when merging 53b0dd1d6d2fda47dda21fcdcea9156fb9b0e209 into 4d4548048275ee25ba698cb0bd411296ff3f2238 - view on LGTM.com

new alerts:

jquast commented 2 years ago

Thanks for this work. Can I please turn your attention to the use-jinja branch? It is mostly completed and simplifies this script a great deal by using jinja2 templates. https://github.com/jquast/wcwidth/compare/use-jinja

The jinja2 branch is to start generating C code and improve performance of this library. If you are interested in helping with that effort, I have been looking for a co-maintainer, your work is good, are you interested?

GalaxySnail commented 2 years ago

Thanks for this work. Can I please turn your attention to the use-jinja branch? It is mostly completed and simplifies this script a great deal by using jinja2 templates. https://github.com/jquast/wcwidth/compare/use-jinja

Yes. Templates can be more readable than code generator. I haven't used jinja2 before, so let me read its documents first.

The jinja2 branch is to start generating C code and improve performance of this library.

I agree, C code will be good. Which should we use, Python/C API or Cython? Python/C API has some disadvantages (for example, reference counting), and there is a WIP replacement named hpy, which may be better.

If you are interested in helping with that effort, I have been looking for a co-maintainer, your work is good, are you interested?

It's my pleasure. 😉

jquast commented 2 years ago

Thanks for your help, access granted

I hope to polish up use-jinja branch and merge this weekend which will include the newest unicode version. I've used both Python/C API and Cython lightly in the past, I've been happier with Cython. I would want whichever is more portable or likely to succeed in build on alternate platforms.

Please forgive me if I take the transition to C a bit slow, because this library is downloaded a lot I want to be sure the installation process very forgiving, to fallback to pure python if no compiler is present, to try to provide binary wheels for top platforms & versions and to do platform testing

jnoortheen commented 2 years ago

@jquast you may be interested in mypyc . It was recently used in black as well.

GalaxySnail commented 2 years ago

you may be interested in mypyc . It was recently used in black as well.

I think the algorithm will be implimented in C, and either Python/C API or cython is only for wrapping the C code in a Python extension module.

AFAIK, mypyc doesn't support pypy. At least, it haven't been tested on pypy, and mypy doesn't distribute any mypyc-compiled wheels for pypy on pypi.org either (There's only cp ABI for cpython). And I doubt that mypyc can provide speed up as much as C code does.

Cython does support pypy (via pypy's cpyext). And cython has a pure python mode (but I haven't used it before, I'm not sure if we can make both cython and mypy's type checker happy). Futher more, if one day cython supports HPy backend, we can get more performance improvement on pypy (and graalpython, and some others).