Mailman 3 January 2015 - docs

[issue20121] quopri_codec newline handling
by Martin Panter 20 Jan '15

20 Jan '15

Martin Panter added the comment: Here is patch v2, which fixes some more bugs I uncovered in the quoted-printable encoders: * The binascii version would unnecessarily break a 76-character line (maximum length) if it would end with an =XX escape code * The native Python version would insert soft line breaks in the middle of =XX escape codes ---------- type: -> behavior Added file: http://bugs.python.org/file37783/quopri-newline.v2.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20121> _______________________________________

1 0

[issue23271] Unicode HOWTO documentation error
by Dionysis Zindros 19 Jan '15

19 Jan '15

New submission from Dionysis Zindros: In the Unicode HOTWO documentation for Python 2.x [0], there's an error in the fourth code sample under the section "The Unicode Type". The code states: ``` >>> s = u'Was ever feather so lightly blown to and fro as this multitude?' >>> s.count('e') 5 >>> s.find('feather') 9 >>> s.find('bird') -1 >>> s.replace('feather', 'sand') u'Was ever sand so lightly blown to and fro as this multitude?' >>> s.upper() u'WAS EVER FEATHER SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?' ``` Notice that in the last line, "sand" was turned back into "feather". The correct last line should have been: ``` u'WAS EVER SAND SO LIGHTLY BLOWN TO AND FRO AS THIS MULTITUDE?' ``` [0] https://docs.python.org/2/howto/unicode.html ---------- assignee: docs@python components: Documentation messages: 234312 nosy: Dionysis.Zindros, docs@python priority: normal severity: normal status: open title: Unicode HOWTO documentation error type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23271> _______________________________________

2 1

[issue16473] quopri module differences in quoted-printable text with whitespace
by Martin Panter 19 Jan '15

19 Jan '15

Martin Panter added the comment: Regarding decoding trailing whitespace, <https://tools.ietf.org/html/rfc1521.html#section-5.1> rule #3 says: “When decoding a Quoted-Printable body, any trailing white space on a line must be deleted, as it will necessarily have been added by intermediate transport agents.” ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16473> _______________________________________

1 0

[issue16473] quopri module differences in quoted-printable text with whitespace
by Martin Panter 19 Jan '15

19 Jan '15

Martin Panter added the comment: Three slightly different points here: 1. Decoding trailing whitespace: My understanding is quoted-printable encoding aims to be tolerant of whitespace being added to and removed from the end of encoded lines. So I assume the “binascii” module is wrong to leave trailing whitespace in the decoded output, and the native “quopri” implementation is correct to ignore it. 2. CRLF handling: See Issue 20121. It seems CRLF newlines should be valid, and I have added a patch to that issue to make the native Python implementation handle CRLF newlines. 3. Whitespace encoding: The quopri-codec actually sets quotetabs=True. Here is a patch to document and test that, as well as correct the functions used by other codecs. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, vadmium title: quopri module minor difference in decoding quoted-printable text -> quopri module differences in quoted-printable text with whitespace Added file: http://bugs.python.org/file37772/codec-impl.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16473> _______________________________________

1 0

[issue18518] return-ing within code timed with timeit.timeit causes wrong return value of timeit.timeit
by Serhiy Storchaka 18 Jan '15

18 Jan '15

Serhiy Storchaka added the comment: If there are no objections I'm going to commit the patch. ---------- assignee: -> serhiy.storchaka _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18518> _______________________________________

1 0

[issue23181] Unicode "code point" should be two words in documentation
by Al Sweigart 18 Jan '15

18 Jan '15

New submission from Al Sweigart: According to http://unicode.org/glossary/ "codepoint" is incorrect and should be changed to "code point". ---------- assignee: docs@python components: Documentation files: code_point_patch.diff keywords: patch messages: 233568 nosy: Al.Sweigart, docs@python priority: normal severity: normal status: open title: Unicode "code point" should be two words in documentation type: behavior versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file37623/code_point_patch.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23181> _______________________________________

4 9

[issue20121] quopri_codec newline handling
by Martin Panter 18 Jan '15

18 Jan '15

Martin Panter added the comment: Here is a patch that clarifies in the documentation and test suite how newlines work in the “quopri” and “binascii” modules. It also fixes the native Python implementation to support CRLFs. * \n is used by default (e.g. for soft line breaks if the input has no hard line breaks) * CRLF is used instead if found in input (even in non-text mode!) * Typo errors in documentation * quopri uses istext=True * header flag does not affect newline encoding; only istext affects it One corner case concerns me slightly: binascii.b2a_qp(istext=False) will use \n for soft line breaks by default, but will suddenly switch to CRLF if the input data happens to contain a CRLF sequence. This is despite the CRLFs from the data being encoded and therefore not appearing in the output themselves. ---------- assignee: -> docs@python components: +Documentation keywords: +patch nosy: +docs@python Added file: http://bugs.python.org/file37756/quopri-newline.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20121> _______________________________________

1 0

[issue23220] IDLE does not display \b backspace correctly.
by Terry J. Reedy 17 Jan '15

17 Jan '15

Terry J. Reedy added the comment: Going back to msdos, there are graphic chars for all 256 bytes, including may single and double line box-drawing chars. Many In Idle, I see 5 solid white circles. In FireFox, there are 5 empty circles (on dark background, which are chr(9689). When I copy from FF back to Idle (3.4.2, Win7), there are 5 of each. I have no idea if the 9689s are on the site or added by FF. Here is another difference. >>> print('\x03') # console ♥ # heart >>> print('\x03') # idle # lower left single line corner in Idle, box on FF Trying to match console-Idle(tk) print output for control chars even on Windows would be tough. --- I have been planning to add a subsection of the doc that mentions known differences between console interpreter and Idle shell. The result of print() is one of them. Another print difference is that Idle displays many unicode chars that Windows replaces with boxes or ?s, depending on the codepage. ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, terry.reedy _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23220> _______________________________________

1 0

[issue17546] Document the circumstances where the locals() dict get updated
by R. David Murray 15 Jan '15

15 Jan '15

R. David Murray added the comment: Yeah, the question of thread-safety in regards to what we are talking about here also occurred to me. That is, the wording makes one wonder if locals is thread safe or not. I don't see your suggested wording as making it clearer, though. The problem is that it *is* underspecified. So I think the correct description of the current under-specification is that locals() returns a copy of the current locals namespace. If you modify the thing returned by locals it may or may not update the local namespace. If you modify the local namespace (by doing x = y or its equivalents) the change may or may not be reflected in the object that was returned by locals(). Now, how do we boil that down? Or do we just say it more or less that way? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17546> _______________________________________

1 0

[issue17546] Document the circumstances where the locals() dict get updated
by Martin Panter 15 Jan '15

15 Jan '15

Martin Panter added the comment: What about instead of ''' Whether changes to one are reflected in the other after the call returns is undefined; additionally, the dictionary may change unpredictably after the call, and how it does is implementation-specific. ''' substitue this wording: ''' Whether changes to one are reflected in the other after the call returns, and when such updates occur, is undefined and implementation-specific. ''' The old wording seems under-specified. It would allow a function call, garbage collection, etc, to clobber the dictionary, say overwriting with another function’s locals(), before you get a chance to work with the dictionary. ---------- nosy: +vadmium _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17546> _______________________________________

1 0