lancopku
几条建议
如果目标是要打造工业级强度的分词工具，那么：
1、按照 PEP8 规范把代码整理一下； 2、不建议支持 Python 2，Python 2 都要淘汰了，这个精力花得不值； 3、模型文件在 GitHub （可以参考 distributing-large-binaries）或者 s3 上放一份； 4、加载模型的时候给出提示（输出相应的日志，而非直接打印到控制台），这样用户可以知道模型什么时候加载完毕，否则会误以为分词本身用了很长时间； 5、和其他分词工具（如 hanlp, LTP 等）进行更全面的对比，以及需要增加关于性能的基准测试（比如每秒能处理多少词）； 6、对标点符号、数字等的特殊处理； 7、增加 C++/Java 接口（假如仅仅是做推断的话，其实更建议 CRF 的部分用 C++ 重写）
如果目标是要打造工业级强度的分词工具，那么：
1、按照 PEP8 规范把代码整理一下； 2、不建议支持 Python 2，Python 2 都要淘汰了，这个精力花得不值； 3、模型文件在 GitHub （可以参考 distributing-large-binaries）或者 s3 上放一份； 4、加载模型的时候给出提示（输出相应的日志，而非直接打印到控制台），这样用户可以知道模型什么时候加载完毕，否则会误以为分词本身用了很长时间； 5、和其他分词工具（如 hanlp, LTP 等）进行更全面的对比，以及需要增加关于性能的基准测试（比如每秒能处理多少词）； 6、对标点符号、数字等的特殊处理； 7、增加 C++/Java 接口（假如仅仅是做推断的话，其实更建议 CRF 的部分用 C++ 重写）
我也提了和你一样的建议，和hanlp、ltp做对比，不过作者把我的issue都close了。。。。
如果目标是要打造工业级强度的分词工具，那么：
1、按照 PEP8 规范把代码整理一下； 2、不建议支持 Python 2，Python 2 都要淘汰了，这个精力花得不值； 3、模型文件在 GitHub （可以参考 distributing-large-binaries）或者 s3 上放一份； 4、加载模型的时候给出提示（输出相应的日志，而非直接打印到控制台），这样用户可以知道模型什么时候加载完毕，否则会误以为分词本身用了很长时间； 5、和其他分词工具（如 hanlp, LTP 等）进行更全面的对比，以及需要增加关于性能的基准测试（比如每秒能处理多少词）； 6、对标点符号、数字等的特殊处理； 7、增加 C++/Java 接口（假如仅仅是做推断的话，其实更建议 CRF 的部分用 C++ 重写）
我们会考虑把您的这些建议加进我们的下一个版本的工具包里。另一方面，除了改进我们的核心功能，我们也正在积极筹备更多领域的预训练语料供大家下载使用。非常感谢您的建议！
