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.

Author pitrou
Recipients chris.jerdonek, ethan.furman, gward, jcea, pitrou, twouters
Date 2012-08-04.00:12:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1344039013.3377.37.camel@localhost.localdomain>
In-reply-to <1344038724.28.0.898759875962.issue15510@psf.upfronthosting.co.za>
Content
Le samedi 04 août 2012 à 00:05 +0000, Chris Jerdonek a écrit :
> Chris Jerdonek added the comment:
> 
> > > wrapping, "leading whitespace in the first line is always preserved,
> > > though."
> > Ok, then it's a bit fuzzy. That whitespace is as much trailing as
> > leading, after all :)
> 
> That's why the word "always" is there. :)

I'm not sure that's the right interpretation. The only point of
preserving whitespace is to preserve indentation, which is pointless
when there's nothing after the whitespace.

> > I'm not sure I see the relevance. strip() returns an empty string
> > because its return type is a string, what else could it return?
> 
> My point was that your line of logic was not as clear-cut as you
> suggested.  One could argue that dropping whitespace to become the
> empty string is more reasonable than dropping it become "no string".

Of course. The point is, if the alternative is no better than the
current behaviour, the status quo wins.

> Is it your opinion that no changes to textwrap should be made in any
> versions that change existing behavior on some input?

As far as these changes don't fix obvious bugs, no, they shouldn't.
People certainly rely on the current behaviour, and they will start
getting extraneous newlines if you change it (because they will call
'\n'.join(...)).
History
Date User Action Args
2012-08-04 00:12:46pitrousetrecipients: + pitrou, twouters, gward, jcea, chris.jerdonek, ethan.furman
2012-08-04 00:12:46pitroulinkissue15510 messages
2012-08-04 00:12:45pitroucreate