Mailman 3 November 2015 - docs

[issue25039] Docs: Link to Stackless Python in Design and History FAQ section is broken
by Camilla Montonen 04 Dec '15

04 Dec '15

New submission from Camilla Montonen: The link to Stackless Python here https://docs.python.org/2/faq/design.html#can-t-you-emulate-threads-in-the-… is broken. I get an "Internal Server Error" when trying to access it. ---------- assignee: docs@python components: Documentation messages: 250297 nosy: Winterflower, docs@python priority: normal severity: normal status: open title: Docs: Link to Stackless Python in Design and History FAQ section is broken versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25039> _______________________________________

4 4

[issue25756] asyncio WriteTransport documentation typo
by Марк Коренберг 02 Dec '15

02 Dec '15

New submission from Марк Коренберг: Here is the match against master. Doc/library/asyncio-protocol.rst: @@ -156,9 +156,9 @@ WriteTransport high-water limit is given, the low-water limit defaults to an implementation-specific value less than or equal to the high-water limit. Setting *high* to zero forces *low* to zero as - well, and causes :meth:`pause_writing` to be called whenever the + well, and causes :meth:`resume_writing` to be called whenever the buffer becomes non-empty. Setting *low* to zero causes - :meth:`resume_writing` to be called only once the buffer is empty. + :meth:`pause_writing` to be called only once the buffer is empty. Use of zero for either limit is generally sub-optimal as it reduces opportunities for doing I/O and computation concurrently. ---------- assignee: docs@python components: Documentation messages: 255508 nosy: docs@python, mmarkk priority: normal severity: normal status: open title: asyncio WriteTransport documentation typo type: enhancement versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25756> _______________________________________

2 1

[issue25767] asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs
by Elizabeth Myers 01 Dec '15

01 Dec '15

New submission from Elizabeth Myers: The link for HPET in the asyncio documentation (18.5.2.3.1 Windows, final paragraph, see https://docs.python.org/3/library/asyncio-eventloops.html#windows) links to https://fr.wikipedia.org/wiki/High_Precision_Event_Timer for the HPET link even though the document is in English (it should link to the English Wikipedia version instead). ---------- assignee: docs@python components: Documentation messages: 255598 nosy: Elizacat, docs@python priority: normal severity: normal status: open title: asyncio documentation section 18.5.2.3.1. (Windows) links to French Wikipedia in English docs type: enhancement versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25767> _______________________________________

3 2

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by Kovid Goyal 30 Nov '15

30 Nov '15

Kovid Goyal added the comment: No worries, as I said, I understand, I would probably do the same, were I in your shoes. I have found that being a maintainer of a complex software project tends to naturally increase conservatism :) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by R. David Murray 30 Nov '15

30 Nov '15

R. David Murray added the comment: Unfortunately it is unlikely we'll merge it, since because of the compiled extension issue we have a negative motivation for supporting anything other than the release compiler currently used. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by Kovid Goyal 30 Nov '15

30 Nov '15

Kovid Goyal added the comment: I take it back, my methodology in reproducing the function calls used by the gzip module was flawed. It does look like a bug in the CRT, but I have not been able to isolate a simple way of reproducing it. I have however, found a workaround for it, that has an acceptable performance impact. https://github.com/kovidgoyal/cpython/commit/72ae720ab057b1ac0402d67a7195d5… Now all tests pass (except for tcl/tk and distutils, neither of which I care about -- well I will probably need to fix up distutils at some point, but not now :). Running testsuite as ./PCbuild/amd64/python_d.exe Lib/test/regrtest.py -u network,cpu,subprocess,urlfetch @steve: Thank you for all the work you did porting python 3.x to VS 2015, that certainly made by life a lot easier. I would of course, be ecstatic if you were to consider merging my work into the python 2.7 branch, but if not, I understand -- no one likes to maintain a legacy codebase. In any case, for interested third parties, my work is available here: https://github.com/kovidgoyal/cpython (2.7 branch) and instructions on building python on windows using a nice cygwin environment are here: https://github.com/kovidgoyal/calibre/blob/master/setup/installer/windows/n… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by Kovid Goyal 30 Nov '15

30 Nov '15

Kovid Goyal added the comment: Doesn't seem like a bug in the CRT, I cannot reproduce in a plain CRT program, so now I get to try to figure out what is broken in fileobject.c by VS 2015. That's a relief :) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0

Re: [docs] Document that tp_setattro and tp_setattr are used for deleting attributes (issue 25701)
by vadmium+py＠gmail.com 30 Nov '15

30 Nov '15

https://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst File Doc/c-api/object.rst (right): https://bugs.python.org/review/25701/diff/16034/Doc/c-api/object.rst#newcod… Doc/c-api/object.rst:72: otherwise set it to *v* (``o.attr_name = v``). Returns ``-1`` on failure. On 2015/11/25 10:54:34, haypo wrote: > Raise an exception and returns -1 on failure, return 0 on success. > > (Same change for other functions below) Done with slightly different wording, also for the new functions referenced in the new patch. https://bugs.python.org/review/25701/diff/16034/Include/abstract.h File Include/abstract.h (right): https://bugs.python.org/review/25701/diff/16034/Include/abstract.h#newcode1… Include/abstract.h:196: (o.attr_name=v). Returns -1 on failure. On 2015/11/25 10:54:34, haypo wrote: > Raise an exception and returns -1 on failure, return 0 on success. Applied slightly different wording to all three modified functions in my new patch. https://bugs.python.org/review/25701/

1 0

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by Kovid Goyal 30 Nov '15

30 Nov '15

Kovid Goyal added the comment: To answer part of my question, the reason the fseek()+fread() bug does not affect python 3.5.0 appears to be because it implements its own buffering and does not use fseek()/fread() at all. Sigh, I really hope the answer does not end up being that I have to re-implement fseek()/ftell()/fread()/fwrite() using lseek()/read()/write() on windows. Or I could wait and hope Microsoft fixes the bug :) As a first step, to confirm that the bug is in the CRT, I'll have the gzip module record all reads/seeks/tells and then see if I can reproduce the bug in a plain C program. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0

[issue25759] Python 2.7.11rc1 not building with Visual Studio 2015
by Kovid Goyal 29 Nov '15

29 Nov '15

Kovid Goyal added the comment: Yes, I am aware. I embed python in my application, which includes large C++ libraries. Those libraries are going to start requiring to be compiled with a modern compiler soon, which means I need python to also be compiled with a modern compiler. I already manually compile all python extensions in my build system, so that is not a problem. And before someone suggests I upgrade to python 3, porting half a million lines of python is simply not worth it for me. I'll be happy to open a separate bug report, but first I want some advice. I have got all the other tests passing as well, except one single test. test_gzip.test_many_append. The reason that test fails is apparently because of a buffering bug in the stdio C functions in VS 2015. Combining lots of seeks relative to SEEK_CUR causes read() to return incorrect data. I can make the test pass by modify the gzip module to open files with bufferring=0, or by putting in a seek(0, 0) to cause the stdio layer to flush its read buffer at the appropriate point. However, this is not an actual fix, just an inefficient workaround. My question is, how do I properly workaround this bug? And how come this bug is not triggered in Python 3.5.0? Am I diagnosing this correctly? Any other alternative explanations? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25759> _______________________________________

1 0