PyHyphen is a mature library that wraps the existing CPython `textwrap` module and provides the ability to break and hyphenate words in wrapped text.

PyHyphen is on PyPI here:

https://pypi.org/project/PyHyphen/

And on GitHub here:

https://github.com/dr-leo/PyHyphen

While the PyPI page and the README file say that PyHyphen uses an Apache 2.0 License, the GitHub repository says that it uses a GPL 2.0/LGPL 2.1/MPL 1.1 tri-license:

https://github.com/dr-leo/PyHyphen/blob/master/LICENSE.txt

To what extent would it be feasible to integrate PyHyphen's enhancements into the core `textwrap` module? It is my understanding that the `textwrap` itself began life as a third-party module, which would suggest that such integrations are somewhat precedented.

I'm not experienced enough to know how to do a pull request myself, and I don't understand the legal details well enough to know if PyHyphen is license-compatible with CPython.

Thank you for the suggestion.

Hyphenation seems like a niche requirement to me, probably too niche and with too many design decisions to include it in the stdlib. It's also not clear to my why PyHyphen would be the best option for this, as opposed to the other hyphenation libraries on PyPI. You'll need to address both of these issues as part of any proposal.

I suggest you bring this up on the python-ideas mailing list in order to get a broader discussion.

I mainly suggested PyHyphen because (at a fairly superficial glance) it has been around for over a decade, and it extends an existing module rather than adding a new one. To be fair, `textwrap` itself is relatively niche, and it's my understanding that it's also a relatively recent addition to the standard library.

I can repost this this to the mailing list, though I'll probably do some more digging first.

Many years ago I write highly optimized hyphenation module (as a part of OrnamentBook project https://sourceforge.net/projects/pybookreader/files/OrnamentBook/). I could contribute the code to the stdlib. But the problem is that the algorithm depends on language specific data files. I am not sure that we are ready to include these files in the stdlib. And how are we going to handle requests for support of new languages and how to validate contributed data files for unknown new languages?

This strikes me as an example of the sort of thing that should not be in the stdlib.  'Correct' behavior is a matter of opinion and the language being hyphenated.  I recommend rejecting.

I concur with Terry.  The suggestion is nice but it belongs outside the standard library.

I agree this doesn’t belong in the stdlib. For future reference, my principal objections are 1) the need to manage and distribute per-language dictionaries and 2) difficulty in determining the best algorithm for the stdlib. There are a lot of ways to tweak this. The community is well served with the multiple libraries on PyPI.