A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2002-June/025217.html below:

[Python-Dev] textwrap.py

[Python-Dev] textwrap.pyPaul Prescod paul@prescod.net
Sun, 09 Jun 2002 11:19:47 -0700
Greg Ward wrote:
> 
>...
> 
> However, I *still* don't want to make all of TextWrapper's options
> keyword arguments to the wrap() method, because 1) I'd be morally bound
> to make them kwargs to the fill() method, and to the standalone wrap()
> and fill() functions as well, which is a PITA; and 2) I think it's
> useful to be able to encode your preferences in an object for multiple
> wrapping jobs.

I buy the second argument but not the first. I'm 95% happy with what you
propose and suggest only a tiny change.

If "expand_tabs" or "replace_whitespace" or "break_long_words" are
options that people will want to specify when doing text wrapping then
why *wouldn't* they be arguments to the wrap and fill functions? The
object is useful for when you want to keep those options persistently.
But it seems clear that you would want to pass the same argument to the
function versions.

Here's my proposed (untested) fix:

def wrap (text, width, **kwargs):
    return TextWrapper(**kwargs).wrap(text, width)

def fill (text, width, initial_tab="", subsequent_tab="", **kwargs):
    return _wrapper.fill(text, width, initial_tab, subsequent_tab,
**kwargs)

I'm not clear on why the "width" argument is special and should be on
the wrap method rather than in the constructor. But I suspect most
people will use the convenience functions so they'll never know the
difference.

 Paul Prescod




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4