On 23/03/20 8:00 AM, Chris Angelico wrote:
When using textwrap.fill() or friends, setting break_long_words=False
without also setting break_on_hyphens=False has the very strange
behaviour that a long hyphenated word will still be wrapped. I
discovered this as a very surprising result when trying to wrap a
paragraph that contained a URL, and wanting the URL to be kept
unchanged:
I dropped textwrap years ago. Which policy likely shows my/my
applications' bias.
Today it feels like an anachronism because it is comes from the era of
fixed-width fonts and line-lengths denominated in characters*. The issue
is that it was designed to re-define 'white space' and to enable the
conversion of text 'wrapped' in one (fixed) format, to suit another.
With the arrival?predominance of proportional-width fonts, the skills of
hyphenation have started to go the way of cursive hand-writing
[substitute any number of grumpy, old man regrets/favorite complaints,
here].
Beyond such syntactic concerns, textwrap applies no semantic meaning to
its text-content. For that we have to move to markup languages (HTML is
my bias - but (largely) presumes screen presentation). Python seems to
prefer reST (eg Sphinx). See also, markdown.
However, it's annoying if one is 'stuck' within a spec and some list
smart-alec comes along saying 'change the tool'...
Your idea of sub-classing (as I'm sure YOU know, textwrap is but a
convenience-function) struck me as clever-thinking! Could textwrap's
'final format' be caught just before 'return', enabling a post-process
to undo anything textwrap has done, and (re-)format the URLs to spec, or
to treat textwrap's output as a template and 'inject' the URL
appropriately? If not a sub-class, a decorator?
My idea (being more simple-minded than you!), would be to partition the
text (yes, am alluding to the Python str.method):
- textwrap the 'early text',
- treat the URL as a string using the required convention,
- textwrap the 'later text', and
- str.join() the three components/partitions afterwards.
Both likely 'force' the URL to occupy a line of its own, and thus create
some odd-looking results!
* that said, my terminal windows and SublimeText are all configured to
use fixed-width fonts - seems easier on the eyes! Similarly, the
mainframe legacy of punched-card input is alive-and-well in Python
'standards', which talk of a 79- or 80-character line-width. Please
don't take me by the ear and wash-out my mouth with soap and water!
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list
