Mailman 3 November 2015 - docs

(no subject)
by Clark Kent Nov. 23, 2015

Nov. 23, 2015

not work downloads links error 404 not found https://docs.python.org/3/download.html

1 0

[issue4744] asynchat documentation needs to be more precise
by R. David Murray Nov. 23, 2015

Nov. 23, 2015

R. David Murray added the comment: OK, let's close it then. If someone finds something wrong they can open a new issue. ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4744> _______________________________________

1 0

[issue4744] asynchat documentation needs to be more precise
by R. David Murray Nov. 23, 2015

Nov. 23, 2015

R. David Murray added the comment: If you've read through the asynchat docs and don't think any of the other mentions of string are incorrect or ambiguous, then we should close it. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4744> _______________________________________

2 1

[issue4744] asynchat documentation needs to be more precise
by R. David Murray Nov. 23, 2015

Nov. 23, 2015

R. David Murray added the comment: Yes. The docs should be accurate, even if the module is deprecated. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4744> _______________________________________

2 2

Multiple bugs in email package and documentation - Python 3.4 (fwd)
by Laura Creighton Nov. 23, 2015

Nov. 23, 2015

Thought this would be of interest to those not reading the docs mailing list. If all of you already read that list, then I apologise for wasting your time. Laura ------- Forwarded Message From: Ervin Hegedüs <airween(a)gmail.com> Subject: [docs] Multiple bugs in email package and documentation - Python 3.4 Hi, looks like I've found a complex, and connected bug in 'email' package. Bug 1: ===== I've read the documentation and examples: [1]https://docs.python.org/3.4/library/email-examples.html I've looked up this example (copy and paste, replace the addresses): [2]https://docs.python.org/3.4/library/email-examples.html# examples-using-the-provisional-api and this example gives a bug: (after several lines, the end of the stack is this) File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in __str__ return quote_string(''.join(str(x) for x in self)) File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in <genexpr> return quote_string(''.join(str(x) for x in self)) RuntimeError: maximum recursion depth exceeded while getting the str of an object Okay, I've commented out the file write method, in line 50. and 51 - then script terminated normally. Bug 2: ===== I've received the e-mail, but the MIME tree of message is completely wrong. I think the original author would like to make a html mail (multipart/ alternative), with embedded image. The regular tree of a html mail is this: I 1 <no description> [multipa/alternativ, 7bit, 0,5K] I 2 ├─><nodescription> [text/plain, quoted, utf-8, 0,1K] I 3 └─><nodescription> [text/html, quoted, utf-8, 0,2K] I 4 attached_image.png [image/png, base64, 43K] but the script in the example gives this tree: I 1 <no description> [multipa/alternativ, 7bit, 101K] I 2 ├─><no description> [text/plain, 8bit, utf-8, 0,1K] I 3 └─><no description> [multipa/related, 7bit, 101K] I 4 ├─><no description> [text/html, quoted, utf-8, 0,3K] I 5 └─><no description> [image/jpeg, base64, 100K] So, the problem is, in a general MUA (Thunderbird, any webmail client...) the image is not visible, but mail contains it. Bug 3: ===== The attached image is "pseduo" base64 encoded. The encode function is defined in email/contenmanager.py: 129 # XXX: This is a cleaned-up version of base64mime.body_encode. It would 130 # be nice to drop both this and quoprimime.body_encode in favor of 131 # enhanced binascii routines that accepted a max_line_length parameter. 132 def _encode_base64(data, max_line_length): 133 encoded_lines = [] 134 unencoded_bytes_per_line = max_line_length * 3 // 4 135 for i in range(0, len(data), unencoded_bytes_per_line): 136 thisline = data[i:i+unencoded_bytes_per_line] 137 encoded_lines.append(binascii.b2a_base64(thisline).decode ('ascii')) 138 return ''.join(encoded_lines) But this code generates this form of base64: --===============8598821442385181731== Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <[3]20151122160934.12051.88999(a)myhost.com> MIME-Version: 1.0 Content-Disposition: inline /9j/ 4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA== BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA == I don't know, why had been created a new encoder here, because there is the email/encoders.py module, which contains a correct base64 encoder. With that, I've got this form (with same image): --===============6414765018955620772== Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <[4]20151122161400.14276.87008(a)myhost.com> MIME-Version: 1.0 Content-Disposition: inline /9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA I've checked this routine with another MIME tree, where image should be visible, but the user agent could't show that. Whit the correct tree and correct encoding, the e-mail visible as correctly, with inline image. I don't know, how can I report this connected bugs? I have a good and working example - but it uses not exactly modules, than in example, however it builds a correct e-mail message. (I don't know, what does it mean the "Provisional API" - and what is the eventual?) Thanks, a. References: [1] https://docs.python.org/3.4/library/email-examples.html [2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p rovisional-api [3] mailto:20151122160934.12051.88999@myhost.com [4] mailto:20151122161400.14276.87008@myhost.com _______________________________________________ docs mailing list docs(a)python.org https://mail.python.org/mailman/listinfo/docs lac@fido:~/Mail/webmaster$ show show (Message inbox:4120) Date: Sun, 22 Nov 2015 18:32:54 +0100 To: docs(a)python.org From: Ervin Hegedüs <airween(a)gmail.com> Subject: [docs] Multiple bugs in email package and documentation - Python 3.4 Hi, looks like I've found a complex, and connected bug in 'email' package. Bug 1: ===== I've read the documentation and examples: [1]https://docs.python.org/3.4/library/email-examples.html I've looked up this example (copy and paste, replace the addresses): [2]https://docs.python.org/3.4/library/email-examples.html# examples-using-the-provisional-api and this example gives a bug: (after several lines, the end of the stack is this) File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in __str__ return quote_string(''.join(str(x) for x in self)) File "/usr/lib/python3.4/email/_header_value_parser.py", line 629, in <genexpr> return quote_string(''.join(str(x) for x in self)) RuntimeError: maximum recursion depth exceeded while getting the str of an object Okay, I've commented out the file write method, in line 50. and 51 - then script terminated normally. Bug 2: ===== I've received the e-mail, but the MIME tree of message is completely wrong. I think the original author would like to make a html mail (multipart/ alternative), with embedded image. The regular tree of a html mail is this: I 1 <no description> [multipa/alternativ, 7bit, 0,5K] I 2 ├─><nodescription> [text/plain, quoted, utf-8, 0,1K] I 3 └─><nodescription> [text/html, quoted, utf-8, 0,2K] I 4 attached_image.png [image/png, base64, 43K] but the script in the example gives this tree: I 1 <no description> [multipa/alternativ, 7bit, 101K] I 2 ├─><no description> [text/plain, 8bit, utf-8, 0,1K] I 3 └─><no description> [multipa/related, 7bit, 101K] I 4 ├─><no description> [text/html, quoted, utf-8, 0,3K] I 5 └─><no description> [image/jpeg, base64, 100K] So, the problem is, in a general MUA (Thunderbird, any webmail client...) the image is not visible, but mail contains it. Bug 3: ===== The attached image is "pseduo" base64 encoded. The encode function is defined in email/contenmanager.py: 129 # XXX: This is a cleaned-up version of base64mime.body_encode. It would 130 # be nice to drop both this and quoprimime.body_encode in favor of 131 # enhanced binascii routines that accepted a max_line_length parameter. 132 def _encode_base64(data, max_line_length): 133 encoded_lines = [] 134 unencoded_bytes_per_line = max_line_length * 3 // 4 135 for i in range(0, len(data), unencoded_bytes_per_line): 136 thisline = data[i:i+unencoded_bytes_per_line] 137 encoded_lines.append(binascii.b2a_base64(thisline).decode ('ascii')) 138 return ''.join(encoded_lines) But this code generates this form of base64: --===============8598821442385181731== Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <[3]20151122160934.12051.88999(a)myhost.com> MIME-Version: 1.0 Content-Disposition: inline /9j/ 4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAAAA== BgEDAAEAAAACAAAAEgEDAAEAAAABAAAAFQEDAAEAAAADAAAAGgEFAAEAAACkAAAAGwEFAAEAAACsAA == I don't know, why had been created a new encoder here, because there is the email/encoders.py module, which contains a correct base64 encoder. With that, I've got this form (with same image): --===============6414765018955620772== Content-Type: image/jpeg Content-Transfer-Encoding: base64 Content-ID: <[4]20151122161400.14276.87008(a)myhost.com> MIME-Version: 1.0 Content-Disposition: inline /9j/4R1zRXhpZgAASUkqAAgAAAAMAAABAwABAAAAWQIAAAEBAwABAAAA3AAAAAIBAwADAAAAngAA AAYBAwABAAAAAgAAABIBAwABAAAAAQAAABUBAwABAAAAAwAAABoBBQABAAAApAAAABsBBQABAAAA I've checked this routine with another MIME tree, where image should be visible, but the user agent could't show that. Whit the correct tree and correct encoding, the e-mail visible as correctly, with inline image. I don't know, how can I report this connected bugs? I have a good and working example - but it uses not exactly modules, than in example, however it builds a correct e-mail message. (I don't know, what does it mean the "Provisional API" - and what is the eventual?) Thanks, a. References: [1] https://docs.python.org/3.4/library/email-examples.html [2] https://docs.python.org/3.4/library/email-examples.html#examples-using-the-p rovisional-api [3] mailto:20151122160934.12051.88999@myhost.com [4] mailto:20151122161400.14276.87008@myhost.com _______________________________________________ docs mailing list docs(a)python.org https://mail.python.org/mailman/listinfo/docs ------- End of Forwarded Message

2 2

[issue4744] asynchat documentation needs to be more precise
by Mark Lawrence Nov. 23, 2015

Nov. 23, 2015

Mark Lawrence added the comment: Does it make sense to spend time updating the asychat docs when https://docs.python.org/3/library/asynchat.html states "Note. This module exists for backwards compatibility only. For new code we recommend using asyncio."? ---------- nosy: +BreamoreBoy _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4744> _______________________________________

1 0

[issue25706] problems in library/base64.rst
by hiroaki itoh Nov. 23, 2015

Nov. 23, 2015

New submission from hiroaki itoh: * default of ignorechars for a85decode b' tnrv' should be b' \t\n\r\v' * explanation of newline for a85encode "newline('n')" should be "newline('\n')" ---------- assignee: docs@python components: Documentation messages: 255155 nosy: docs@python, xwhhsprings priority: normal severity: normal status: open title: problems in library/base64.rst versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25706> _______________________________________

4 9

[issue4744] asynchat documentation needs to be more precise
by Martin Panter Nov. 23, 2015

Nov. 23, 2015

Martin Panter added the comment: I think it would be okay to keep this issue open to address the other mentions of “strings”. Nitika’s patch is missing the special --- and @@ indicator lines at the top, which is probably why it was rejected. Usually you make a patch by using a “diff” command (standalone, with Mercurial, etc). ---------- nosy: +martin.panter _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue4744> _______________________________________

2 1

[issue25706] problems in library/base64.rst
by Stéphane Wirtel Nov. 23, 2015

Nov. 23, 2015

Stéphane Wirtel added the comment: Who can explain the problem ? I am ignorant about this issue. ---------- nosy: +matrixise _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25706> _______________________________________

1 0

[issue25701] Document that tp_setattro and tp_setattr are used for deleting attributes
by Serhiy Storchaka Nov. 23, 2015

Nov. 23, 2015

Changes by Serhiy Storchaka <storchaka(a)gmail.com>: ---------- Removed message: http://bugs.python.org/msg255130 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25701> _______________________________________

1 0