docs April 2014

docs@python.org

26 participants
559 discussions

[issue10976] json.loads() raises TypeError on bytes object

by Hanxue Lee

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> _______________________________________

7 years, 5 months

[issue21154] Small fix in 2.7.6 lang ref

by Armin Rigo

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> _______________________________________

7 years, 5 months

[issue20375] ElementTree: Document handling processing instructions

by Nikolaus Rath

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> _______________________________________

7 years, 5 months

threading

by Onder Hazaroglu

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

7 years, 5 months

[issue21143] Copy-paste error in documentation of __builtin__.max

by Jyrki Pulliainen

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> _______________________________________

7 years, 5 months

Re: [docs] ElementTree: Document handling processing instructions (issue 20375)

by Nikolaus＠rath.org

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/

7 years, 5 months

Re: [docs] ElementTree: Document handling processing instructions (issue 20375)

by eliben＠gmail.com

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/

7 years, 5 months

[issue21125] traceback.extract_tb says "quadruple" when it means "tuple"

by Glenn Maynard

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> _______________________________________

7 years, 5 months

[issue15067] sqlite3 docs reference PEP 246, which was rejected

by Zachary Ware

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> _______________________________________

7 years, 5 months

Jump to page:

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs April 2014