I traced it down. Here's a minimal test case:

text = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\n32-bit-only'

import textwrap
x = textwrap.wrap(text, width=76)
print(x)

Without the bugfix, the line is split between "32" and "-". With the bugfix applied "32-bit-only" remains one word.

The behavior was changed in git revision 72bd327db0b, checked in 2015-03-24 by Serhiy Storchaka, in regards to issue bpo-22687 ("horrible performance of textwrap.wrap() with a long word"). This made it into 3.5.0a3, but has never been backported to 3.4, and at this point it shouldn't be as 3.4 is in security-fixes-only mode.

So, uh, maybe blurb can't support 3.4? Unless we wanna do something crazy like monkeypatch textwrap or something.

We'll have to hear from the infra team about the possibility of upgrading Python. I went on the path of backporting blurb to 3.4 because it seemed easier and faster (and was not excluding a future upgrade). If it's hard, it's the wrong way.

The compromise may be: If the software upgrade take a long time, we'll still be able to merge this so blurb work (with a single strange space) in the meantime. I don't know what it take, I'll ask.

I'm closing this. Won't fix as this is a bug in textwrap, and blurb won't support Python 3.4.