Mailman 3 April 2014 - docs

[issue10976] json.loads() raises TypeError on bytes object
by Hanxue Lee 04 Apr '14

04 Apr '14

Hanxue Lee added the comment: This seems to be an issue (bug?) for Python 3.3 When calling json.loads() with a byte array, this is the error json.loads(response.data, 'latin-1') TypeError: can't use a string pattern on a bytes-like object When I decode the byte array to string json.loads(response.data.decode(), 'latin-1') I get this error TypeError: bytes or integer address expected instead of str instance ---------- nosy: +Hanxue.Lee _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10976> _______________________________________

1 0

[issue21154] Small fix in 2.7.6 lang ref
by Armin Rigo 04 Apr '14

04 Apr '14

New submission from Armin Rigo: The docs still say that the default __hash__() is equal to id(), but that's not the case since Python 2.7. ---------- assignee: docs@python components: Documentation files: lang-ref-fix.diff keywords: patch messages: 215517 nosy: arigo, docs@python priority: normal severity: normal status: open title: Small fix in 2.7.6 lang ref versions: Python 2.7 Added file: http://bugs.python.org/file34723/lang-ref-fix.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21154> _______________________________________

2 1

[issue20375] ElementTree: Document handling processing instructions
by Nikolaus Rath 04 Apr '14

04 Apr '14

New submission from Nikolaus Rath: (This issue was branched of from #9521). When parsing XML, etree currently skips over all processing instructions and comments. However, both can be represented in the tree and are also written out when generating XML. The attached patch documents this (IMO surprising) behavior. ---------- assignee: docs@python components: Documentation files: xml.etree_r1.patch keywords: patch messages: 209036 nosy: docs@python, eli.bendersky, eric.araujo, ezio.melotti, georg.brandl, nikolaus.rath, scoder priority: normal severity: normal status: open title: ElementTree: Document handling processing instructions type: enhancement versions: Python 2.7, Python 3.3, Python 3.4 Added file: http://bugs.python.org/file33675/xml.etree_r1.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20375> _______________________________________

6 17

threading
by Onder Hazaroglu 03 Apr '14

03 Apr '14

Hello, I've been using threading library to run some experiments parallel. There is no message passing between my threads but still it messes up somehow. The results are different than running it separated. Basically I experiment with three threads working on three different files but the results are different than running three of them sequentially. Is there a way to make sure that there is no memory sharing between threads? -- Best Regards, Onder HAZAROGLU | Graduate Student | Ph.D. Candidate University of Arkansas at Little Rock | Computer Science Department EIT Bldg. | (501) 615-3851 | oxhazaroglu(a)ualr.edu, onderhazaroglu(a)gmail.com

2 1

[issue21143] Copy-paste error in documentation of __builtin__.max
by Jyrki Pulliainen 03 Apr '14

03 Apr '14

New submission from Jyrki Pulliainen: Looks like the documentation of the __builtin__.max() got copied over from the __builtin__.min. Instead of "the smallest of the positional arguments" it should say "the largest of the positional arguments". This was introduced in 3.4. Patch attached. Thanks to chiman(a)#python.fi for spotting this! ---------- assignee: docs@python components: Documentation files: fix-typo-in-max.patch keywords: patch messages: 215434 nosy: docs@python, nailor priority: normal severity: normal status: open title: Copy-paste error in documentation of __builtin__.max versions: Python 3.4, Python 3.5 Added file: http://bugs.python.org/file34712/fix-typo-in-max.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21143> _______________________________________

4 3

Re: [docs] ElementTree: Document handling processing instructions (issue 20375)
by Nikolaus＠rath.org 03 Apr '14

03 Apr '14

Thanks for your feedback! I've attached an updated patch. http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… File Doc/library/xml.etree.elementtree.rst (right): http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:114: input. Processing instructions and comments can nevertheless be On 2014/04/02 15:26:31, eli.bendersky wrote: > I think this could be made clearer. Something like "trees built using this > module's API rather than parsing from XML test can have comments and processing > instructions in them, and are included...." > Done. http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:396: Note that the element tree XML parser skips over comments in the On 2014/04/02 15:26:31, eli.bendersky wrote: > Replace "the element tree XML parser" with a properly ReST-linked "ElementTree", > as done elsewhere in the document. Done. http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:399: into to the tree using :meth:`~Element.insert`, On 2014/04/02 15:26:31, eli.bendersky wrote: > I don't think this listing is necessary - there are many ways to create new > Element nodes... Done. http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:483: instructions in the input instead of creating objects for them. An On 2014/04/02 15:26:31, eli.bendersky wrote: > same comments here as for the previous block. Done. http://bugs.python.org/review/20375/

1 0

Re: [docs] ElementTree: Document handling processing instructions (issue 20375)
by eliben＠gmail.com 02 Apr '14

02 Apr '14

http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… File Doc/library/xml.etree.elementtree.rst (right): http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:114: input. Processing instructions and comments can nevertheless be I think this could be made clearer. Something like "trees built using this module's API rather than parsing from XML test can have comments and processing instructions in them, and are included...." http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:396: Note that the element tree XML parser skips over comments in the Replace "the element tree XML parser" with a properly ReST-linked "ElementTree", as done elsewhere in the document. http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:399: into to the tree using :meth:`~Element.insert`, I don't think this listing is necessary - there are many ways to create new Element nodes... http://bugs.python.org/review/20375/diff/11483/Doc/library/xml.etree.elemen… Doc/library/xml.etree.elementtree.rst:483: instructions in the input instead of creating objects for them. An same comments here as for the previous block. http://bugs.python.org/review/20375/

1 0

[issue21125] traceback.extract_tb says "quadruple" when it means "tuple"
by Glenn Maynard 02 Apr '14

02 Apr '14

New submission from Glenn Maynard: https://docs.python.org/2/library/traceback.html "A “pre-processed” stack trace entry is a quadruple (filename, line number, function name, text) representing the information that is usually printed for a stack trace." There's no such thing as a "quadruple". This should be "tuple". ---------- assignee: docs@python components: Documentation messages: 215326 nosy: Glenn.Maynard, docs@python priority: normal severity: normal status: open title: traceback.extract_tb says "quadruple" when it means "tuple" _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21125> _______________________________________

4 5

[issue15067] sqlite3 docs reference PEP 246, which was rejected
by Zachary Ware 01 Apr '14

01 Apr '14

New submission from Zachary Ware <zachary.ware(a)gmail.com>: See: http://hg.python.org/cpython/file/d31e83497c5a/Doc/library/sqlite3.rst#l708 PEP 246 is headed by: """ Rejection Notice I'm rejecting this PEP. Something much better is about to happen; it's too early to say exactly what, but it's not going to resemble the proposal in this PEP too closely so it's better to start a new PEP. GvR. """ I don't know what the "something much better" was/is, so I have no idea how that line in the docs should be replaced, but I don't think the PEP 246 reference is valid. Thanks, Zach ---------- assignee: docs@python components: Documentation messages: 162797 nosy: docs@python, ghaering, zach.ware priority: normal severity: normal status: open title: sqlite3 docs reference PEP 246, which was rejected versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15067> _______________________________________

4 12