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 mouse07410
Recipients docs@python, georg.brandl, martin.panter, matrixise, mouse07410, r.david.murray
Date 2015-11-06.13:51:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1446817861.07.0.713138097141.issue25495@psf.upfronthosting.co.za>
In-reply-to
Content
> my patch should be valid for 3.5 also.
> The relevant wording is identical to 2.7.

OK.

> I have resisted removing the magic number 57 for a couple
> of reasons. Reading existing code that uses this number may
> be harder.

You expect to see "existing code that uses this number" in Python-3.5+? Interesting... (Care to point me at a couple of samples of such "existing" Python-3 code?) And you expect that the main info source for understanding the reason behind that "57" (assuming this function is invoked that way, as opposed to splitting the output :) would be the doc for this function, rather than the main program, or RFC 2045, or...? Fine.

> It helps explain how the function was originally to be used,
> and why the newline is appended.

Pardon me, but why do you think anybody would care...? There are tons of functions, old and new, with more new ones popping up fast enough. I'd really envy a person who has time to enjoy history of one minuscule function of an old (albeit still useful :) library.

OK. You think a history of this function should be documented - fine. I don't need it (and don't think anybody else wants to read it either), but it's not my doc or my decision.

Just get the darn bug fixed.
History
Date User Action Args
2015-11-06 13:51:01mouse07410setrecipients: + mouse07410, georg.brandl, r.david.murray, docs@python, martin.panter, matrixise
2015-11-06 13:51:01mouse07410setmessageid: <1446817861.07.0.713138097141.issue25495@psf.upfronthosting.co.za>
2015-11-06 13:51:01mouse07410linkissue25495 messages
2015-11-06 13:51:00mouse07410create