-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add old tables #28
Comments
Sorry for being so late to the conversation, but I am interested in joining forces :) And I do have time for this etched out in the coming weeks. As far as wcwidth goes, the PR is to clean up the build infrastructure, so it's very much similar to the needs of unicodedata2's build infrastructure. I'll be sure to sit down and study unicodedata2 before I go any further with jquast/wcwidth#23 changes. |
If there was something both of our packages could use, it would be "well-structured unicode data", the TXT files well-parsed and annotated, with the copyrights and dates and comments if possible, maybe just some json or toml data files. If a CLI utility existed that helped navigate, fetch & parse the unicode text files archive, and spit out data blobs, this CLI tool could be a @jayvdb: analysis of changes by version, through |
@jquast , what about if The caller would then extract the info they needed from one version, and then switch and repeat with the other version? |
It would be useful to be able to refer to tables for the previous versions of Unicode.
jquast/wcwidth#23 is attempting to do that.
It would also be very helpful to faciliate Python based analysis of the changes in Unicode data.
It seems the build infrastructure of unicodedata2 is perfect for that.
In order to avoid forcing all users to install all data, perhaps a separate PyPI package name could be used for the 'all unicodedata versions' edition of this.
The text was updated successfully, but these errors were encountered: