kengdic
unihan-etl
Our great sponsors
| kengdic | unihan-etl | |
|---|---|---|
| 1 | 1 | |
| 101 | 51 | |
| - | - | |
| 0.0 | 9.5 | |
| 8 months ago | 10 days ago | |
| Python | Python | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
kengdic
-
Some questions about romanization/pronunciation of composite consonants as 받침
I began working on an algorithm to romanize Hangul, but I realized there are a lot of edge cases to cover, especially when the final consonant of one syllable flows into the initial consonant of the next syllable. My knowledge of Korean words is near zero, so to come up with words that match the edge cases, I downloaded a list of Korean words with about 130,000 entries from https://github.com/garfieldnate/kengdic.
unihan-etl
-
Using Mypy in Production
I am moving all my open source projects to `mypy --strict`. Here's the diff of adding basic / --strict mypy types:
libvcs: https://github.com/vcs-python/libvcs/pull/362/files, https://github.com/vcs-python/libvcs/pull/390/files
libtmux: https://github.com/tmux-python/libtmux/pull/382/files, https://github.com/tmux-python/libtmux/pull/383/files
unihan-etl: https://github.com/cihai/unihan-etl/pull/255/files, https://github.com/cihai/unihan-etl/pull/257/files
As for return on investment - not sure yet. What I like about it is:
- completions (through annotating)
- typings can be used downstream (since the above are all now typed python libraries)
- maintainability and bug finding. Easy to wire into CI and run locally.
There's a thread on mypy, "--strict is too strict to be useful", https://github.com/python/mypy/issues/7767. I'm not sure if I walked away with that impression. If I have a function that could potentially return `None` (`Optional[str]` or `str | None`) - it makes sense for the user to handle such a case. They could:
assert response is not None
What are some alternatives?
uniunihan-db - Chinese character dictionary for learning Sino-xenic languages
libtmux - ⚙️ Python API / wrapper for tmux
rjecnik-hrvatskih-jezika - Rječnik hrvatskih jezika
flakeheaven - flakeheaven is a python linter built around flake8 to enable inheritable and complex toml configuration.
jiten - jiten - japanese android/cli/web dictionary based on jmdict/kanjidic — 日本語 辞典 和英辞典 漢英字典 和独辞典 和蘭辞典
pyright - Static Type Checker for Python
Wox.Plugin.eDict - Easy Dictionary Plugin of offline Merriam Webster Dictionary for Wox
eng - Translate British English into American English in text files and Python code
mypy - Optional static typing for Python
python-jamo - Hangul syllable decomposition and synthesis using jamo.
pydantic - Data validation using Python type hints