Issue 12914: Add cram function to textwrap (original) (raw)

Created on 2011-09-06 16:28 by eric.araujo, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (5)
msg143625 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-06 16:28
The pydoc module has a cram function that could be useful to Python authors, if we made it public (textwrap sounds like a great place).
msg143795 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-09-09 19:29
It is already available: >>> import pydoc >>> pydoc.cram('This sentence is too long to fit the space I have made available', 28) 'This sentenc...ade available' def cram(text, maxlen): """Omit part of a string if needed to make it fit in a maximum length.""" if len(text) > maxlen: pre = max(0, (maxlen-3)//2) post = max(0, maxlen-3-pre) return text[:pre] + '...' + text[len(text)-post:] return text It could be documented in place, or moved and imported into pydoc. I am +0 at the moment.
msg143823 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2011-09-10 01:16
A few thoughts: * no one has ever made a request for this * different people may want to do it in different ways (the formulas are hard-wired). * the '...' connector is hardwired (perhaps ' ... ' would look less odd). * we should have a preference for keeping APIs small (more to learn and remember) * this is dirt simple string processing and not hard for people to roll their own if the need arises * if the API were to be expanded, perhaps it should be as a part of a focuses, thoughtful effort to provide a more generic set of text formatting transformations perhaps modeled on deep experiences with similar modules in other languages. (as opposed to piecemeal additions that weren't designed with a coherent vision).
msg143844 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2011-09-10 17:08
This pretty well summarizes my vague feelings. I originally used a size 30 in my example, getting 'This sentence...made available' and then realized that it was a complete accident that I got complete words. If anything were made publicly available, I might like a more sophisticated algorithm. I think other things in pydoc are more worth of consideration. So I am now -.5 or more and would not mind closing this one of the four new pydoc exposure issues.
msg143904 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2011-09-12 15:28
> if the API were to be expanded, perhaps it should be as a part of a > focuse[d], thoughtful effort to provide a more generic set of text > formatting transformations perhaps modeled on deep experiences with > similar modules in other languages. (as opposed to piecemeal additions > that weren't designed with a coherent vision). That’s a very strong point. Thanks for the opinions.
History
Date User Action Args
2022-04-11 14:57:21 admin set github: 57123
2011-09-12 15:28:41 eric.araujo set messages: + stage: resolved
2011-09-11 08:28:29 rhettinger set status: open -> closedresolution: rejected
2011-09-10 17:08:34 terry.reedy set messages: +
2011-09-10 01:16:08 rhettinger set messages: +
2011-09-10 00:59:16 rhettinger set assignee: rhettingernosy: + rhettinger
2011-09-09 19:29:07 terry.reedy set nosy: + terry.reedymessages: +
2011-09-06 16:28:06 eric.araujo create