This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Add cram function to textwrap
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: eric.araujo, rhettinger, terry.reedy
Priority: normal Keywords:

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:21adminsetgithub: 57123
2011-09-12 15:28:41eric.araujosetmessages: + msg143904
stage: resolved
2011-09-11 08:28:29rhettingersetstatus: open -> closed
resolution: rejected
2011-09-10 17:08:34terry.reedysetmessages: + msg143844
2011-09-10 01:16:08rhettingersetmessages: + msg143823
2011-09-10 00:59:16rhettingersetassignee: rhettinger

nosy: + rhettinger
2011-09-09 19:29:07terry.reedysetnosy: + terry.reedy
messages: + msg143795
2011-09-06 16:28:06eric.araujocreate