[issue26689] Add `has_flag` method to `distutils.CCompiler`

[Sylvain Corlay]

Sylvain Corlay added the comment:

New version of the patch using the context manager.

--
Added file: http://bugs.python.org/file42363/has_flag.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional

[Martin Panter]

Martin Panter added the comment:

Playing with Steven and Paul’s patches, they both seem to work well. Paul’s 
seems to have debug printing included, which should be removed. I confirmed 
both patches also seem to address the nargs="?" case (Issue 24223).

At the moment I have zero knowledge of how the argparse internals work. Are 
there any advantages of one patch over the other?

--
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6953] readline documentation needs work

[Martin Panter]

Martin Panter added the comment:

Here is v3 which adds “. . . in the underlying library” for all the function 
and variable references.

--
Added file: http://bugs.python.org/file42362/readline-doc.v3.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24911] Context manager of socket.socket is not documented

[Martin Panter]

Martin Panter added the comment:

FWIW I discovered that socket.close() or __exit__() does not actually raise 
exceptions for cases like EBADF, see Issue 26685.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26685] Raise errors from socket.close()

[Martin Panter]

Martin Panter added the comment:

Here is socket.close.v2.patch which hopefully fixes the test for Windows (still 
untested by me though)

--
Added file: http://bugs.python.org/file42361/socket.close.v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26685] Raise errors from socket.close()

[Martin Panter]

Martin Panter added the comment:

Victor suggested making these errors be reported by the finalize method 
(garbage collection). I started investigating this, but faced various test 
suite failures (test_io, test_curses), as well as many new unhandled exceptions 
printed out during the tests which do not actually trigger failures. Maybe this 
could become a worthwhile change, but it needs more investigation and wasn’t my 
original intention. Finalize-exception.patch is my patch so far.

There are many comments over the place that make me uneasy about this change, 
so I think it should be investigated separately. E.g. Modules/_io/iobase.c:

/* Silencing I/O errors is bad, but printing spurious tracebacks is
   equally as bad, and potentially more frequent (because of
   shutdown issues). */

Lib/_pyio.py:

# The try/except block is in case this is called at program
# exit time, when it's possible that globals have already been
# deleted, and then the close() call might fail.  Since
# there's nothing we can do about such failures and they annoy
# the end users, we suppress the traceback.

--
Added file: http://bugs.python.org/file42360/finalize-exception.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Jason Madden]

Jason Madden added the comment:

I'm sorry, I'm still not following the argument that `write` is likely to 
return nothing. `RawIOBase` and `BufferedIOBase` both document that `write` 
must return the number of written bytes; if you don't return that, you break 
anything that assumes you do, as documented (because both patterns for checking 
if you need to keep looping are both TypeErrors: `written = 0; written += None` 
and `None < len(data)`); and if you ignore the return value, you fail when 
using any `IOBase` object that *isn't* buffered (exactly this case).

But you are definitely right, explicitly checking for None can be done. It adds 
a trivial amount of overhead, but this isn't a production server. The only cost 
is code readability.

Good point about the explicit calls to `flush()`, I thought flush was a no-op 
in some streams, but that's only the case for streams where it doesn't already 
matter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Martin Panter]

Martin Panter added the comment:

My worry was that it is easy to make a write() method that does not return 
anything, but is still useful in most cases. Since BufferedIOBase.write() has 
to guarantee to write everything, it may not seem important to return a value. 
But we could explicitly check for None as you suggested.

In the BaseHandler class, each chunk yielded by the application is passed to 
BaseHandler.write(). But that method calls self._flush(), which should avoid 
any buffering problem. SimpleHandler._flush() implements this by calling 
self.stdout.flush().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Jason Madden]

Jason Madden added the comment:

`self.stdin` and `self.stderr` are documented to be `wsgi.input` and 
`wsgi.errors`, which are both described as "file-like" objects, meaning that 
the `write` method should return bytes written. It seems like the same could 
reasonably be said to be true for `self.stdout`, though it isn't strictly 
documented as such.

The WSGI spec says that each chunk the application yields should be written 
immediately, with no buffering 
(https://www.python.org/dev/peps/pep-/#buffering-and-streaming), so I don't 
think having the default output stream be buffered would be in compliance.

If there is a compatibility problem, writing the loop this way could bypass it 
(untested):

  def _write(self, data):
written = self.stdout.write(data)
while written is not None and written < len(data):
written += self.stdout.write(data[written:])

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Jason Madden]

Jason Madden added the comment:

Is there an expected `self.stdout` implementation that doesn't return the 
number of bytes it writes? `sys.stdout` does, as does `io.RawIOBase`. It 
doesn't seem clear to me that practically speaking there's a compatibility 
problem with requiring that for `self.stdout`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Martin Panter]

Martin Panter added the comment:

Okay now I see the conflict. The use of WSGIRequestHandler with wbufsize = 0 
was the missing key. I see two possible solutions:

1. Change SimpleHandler._write() to allow self.stdout to be a RawIOBase writer, 
and loop over stdout.write() until all the data is written. This seems to be 
what most people are suggesting here. But it requires that stdout.write() 
returns the number of bytes written, so could be a compatibility problem.

2. Document that the SimpleHandler(stdout=...) parameter should be a 
BufferedIOBase writer, and fix WSGIRequestHandler to pass in a BufferedWriter 
(by overriding the wbufsize attribute with -1 or io.DEFAULT_BUFFER_SIZE).

I am not super familiar with the wsgiref package, but the second option seems 
more preferable to me and more in line with my understanding of how it was 
intended to work.

--
stage: test needed -> needs patch
versions: +Python 3.6 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346874] httplib simply ignores CONTINUE

[Patrick J McNerthney]

Patrick J McNerthney added the comment:

"(though I don’t understand why Apache doesn’t renegotiate while the request 
body is being sent)"

Apache does attempt to do this, but HttpsConnection is immediately sending the 
body of the request as fast as the socket will allow, which fills up the 
SSLRenegBuffer before the renegotiation can occur.

"Or perhaps a new method that explicitly waits for the 100 response."

That is likely a good idea. My httplib.py fork did change the behavior of the 
endheaders method to return a response object if there was an error returned in 
response to the "Expect: 100-continue".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Jason Madden]

Jason Madden added the comment:

Django uses a `wsgiref.simple_server` to serve requests, which in turn uses 
`socketserver.StreamRequestHandler` to implement its `WSGIRequestHandler`. That 
base class explicitly turns off buffering for writes (`wbufsize = 0` is the 
class default which gets passed to `socket.makefile`). So that explains how 
there's no `BufferedWriter` wrapped around the `SocketIO` instance.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24291] wsgiref.handlers.SimpleHandler truncates large output blobs

[Jason Madden]

Jason Madden added the comment:

gevent has another simple reproducer for this. I do believe it's not gevent's 
fault, the fault is in the standard library; SimpleHandler._write needs to loop 
until `sent += self.stdeout.write(data)` is `len(data)`.

I have written up more on this at 
https://github.com/gevent/gevent/issues/778#issuecomment-205046001 For 
convenience I'll reproduce the bulk of that comment here:

The user supplied a django application that produced a very large response that 
was getting truncated when using gevent under Python 3.4. (I believe gevent's 
non-blocking sockets are simply running into a different buffering behaviour, 
making it more likely to be hit under those conditions simply because they are 
faster).

This looks like a bug in the standard library's `wsgiref` implementation.

I tracked this down to a call to `socket.send(data)`. This method only sends 
whatever portion of the data it is possible to send at the time, and it returns 
the count of the data that was sent. The caller of `socket.send()` is 
responsible for looping to make sure the full `len` of the data is sent. This 
[is clearly 
documented](https://docs.python.org/3/library/socket.html#socket.socket.send). 

In this case, there is a call to `send` trying to send the full response, but 
only a portion of it is able to be immediately written. Here's a transcript of 
the first request (I modified gevent's `socket.send` method to print how much 
data is actually sent each time):

```
Django version 1.9.5, using settings 'gdc.settings'
Starting development server at http://127.0.0.1:8000/
Quit the server with CONTROL-C.
SENDING 17
SENT 17 OF 17
SENDING 37
SENT 37 OF 37
SENDING 38
SENT 38 OF 38
SENDING 71
SENT 71 OF 71
SENDING 1757905
SENT 555444 OF 1757905
[03/Apr/2016 19:48:31] "GET / HTTP/1.1" 200 1757905
```

Note that there's no retry on the short send.

Here's the stack trace for that short send; we can clearly see that there is no 
retry loop in place:

```
  //3.4/lib/python3.4/wsgiref/handlers.py(138)run()
136 self.setup_environ()
137 self.result = application(self.environ, self.start_response)
--> 138 self.finish_response()
139 except:
140 try:

  //3.4/lib/python3.4/wsgiref/handlers.py(180)finish_response()
178 if not self.result_is_file() or not self.sendfile():
179 for data in self.result:
--> 180 self.write(data)
181 self.finish_content()
182 finally:

  //3.4/lib/python3.4/wsgiref/handlers.py(279)write()
277
278 # XXX check Content-Length and truncate if too many bytes 
written?
--> 279 self._write(data)
280 self._flush()
281

  //3.4/lib/python3.4/wsgiref/handlers.py(453)_write()
451
452 def _write(self,data):
--> 453 self.stdout.write(data)
454
455 def _flush(self):

  //3.4/lib/python3.4/socket.py(398)write()
396 self._checkWritable()
397 try:
--> 398 return self._sock.send(b)
399 except error as e:
400 # XXX what about EINTR?

> //gevent/_socket3.py(384)send()
382 from IPython.core.debugger import Tracer; Tracer()() ## 
DEBUG ##
383
--> 384 return count
```

`self.stdout` is an instance of `socket.SocketIO` (which is returned from 
`socket.makefile`). This is not documented on the web, but the [docstring also 
clearly 
documents](https://github.com/python/cpython/blob/3.4/Lib/socket.py#L389) that 
callers of `write` should loop to make sure all data gets sent.

--
nosy: +jmadden
versions: +Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26606] logging.baseConfig is missing the encoding parameter

[Jānis Šlapiņš]

Jānis Šlapiņš added the comment:

> that's why I'm choosing not to increase the complexity of my code

I disagree about the classification of my proposal. This is not about 
increasing the complexity (changing algorithms, adding a new functionality and 
so on). It is just about getting the most out of the code with a minimum effort.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10910] pyport.h FreeBSD/Mac OS X "fix" causes errors in C++ compilation

[Dimitry Andric]

Dimitry Andric added the comment:

I am a FreeBSD committer, and I recently ran into this issue too, since I am 
working on an update of libc++ in the FreeBSD base system.  As part of this 
work, we attempt to recompile all ports with the proposed change (see [1]).  
During such a recompile, we get many errors in ports that include pyport.h in 
C++ mode, similar to (see [2]):

In file included from scipy/interpolate/src/_interpolate.cpp:4:
In file included from scipy/interpolate/src/interpolate.h:3:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
/usr/include/c++/v1/__locale:468:15: error: C++ requires a type specifier for 
all declarations
char_type toupper(char_type __c) const
  ^
/usr/local/include/python2.7/pyport.h:731:29: note: expanded from macro 
'toupper'
#define toupper(c) towupper(btowc(c))
^

I think Ronald's proposed workaround is fine, since messing with ctype macros 
is risky in C++ mode.  E.g. the libc++  header explicitly undefines 
all ctype macros, and replaces them with inline functions.

Additionally, the original issue mentioned in changeset 32950 [3] was fixed in 
October 2007 for FreeBSD 8.x [4], and subsequently the fix was merged back to 
FreeBSD 6.x and 7.x [5].

I'm adding an additional diff that corrects the __FreeBSD_version number 
checks.  This will also be submitted to the FreeBSD ports bug tracker.

[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208158
[2] 
http://package18.nyi.freebsd.org/data/headamd64PR208158-default/2016-03-22_18h30m05s/logs/errors/py27-scipy-0.16.1.log
[3] https://hg.python.org/cpython/rev/adfe7d39a049
[4] https://svnweb.freebsd.org/base?view=revision=172619
[5] https://svnweb.freebsd.org/base?view=revision=172929

--
nosy: +dim
Added file: http://bugs.python.org/file42359/issue10910-fix-versionchecks-1.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1346874] httplib simply ignores CONTINUE

[Martin Panter]

Martin Panter added the comment:

Thankyou, I think I understand your situation better now (though I don’t 
understand why Apache doesn’t renegotiate while the request body is being sent).

I would still argue that this is a new feature to be added rather than a bug 
though, and should only go into Python 3.6+. The original HTTP 1.1 
specification (RFC 2068) did not even mention an “Expect: 100-continue” header 
field, although it does mention the “100 Continue” response. And any change 
will probably need new APIs and documentation.

Rather than parsing the headers for “100-continue”, I wonder if it would be 
cleaner adding an API flag to add the header. Or perhaps a new method that 
explicitly waits for the 100 response.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25974] Fix statistics.py after the Decimal.as_integer_ratio() change

[Stefan Krah]

Stefan Krah added the comment:

Ping. Just a reminder that it would be nice to get this into 3.6-alpha-1. :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26200] SETREF adds unnecessary work in some cases

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Reraised this issue on Python-Dev: 
http://comments.gmane.org/gmane.comp.python.devel/156809 .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26680] Incorporating float.is_integer into the numeric tower and Decimal

[Stefan Krah]

Stefan Krah added the comment:

I've been thinking about this, and I'm +1 for the change now.

These structural typing issues for numbers come up regularly
(see also msg257088), and the functions are so simple and
self-explanatory that API-complexity does not really increase.


In general, I understand the argument that Python has become
too complex in some areas -- recently I had to go back to
Python-2.7 in order to understand a certain detail about
.pyc files (in 2.7 it was immediately obvious).


But here I see on such problems.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26479] Init documentation typo "may be return" > "may NOT be returned"

[Samuel Colvin]

Samuel Colvin added the comment:

Sorry, I'm going mad, misread it.

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21069] test_fileno of test_urllibnet intermittently fails

[Martin Panter]

Martin Panter added the comment:

Yes using select() would be another way to fix the immediate problem of read() 
returning None. In the long term I was hoping to use something like my patch to 
avoid the problems with reading the HTTP response (already discussed in this 
report) at the same time.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26689] Add `has_flag` method to `distutils.CCompiler`

[SilentGhost]

SilentGhost added the comment:

I've left a comment on Rietveld

--
nosy: +SilentGhost

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23735] Readline not adjusting width after resize with 6.3

[Martin Panter]

Martin Panter added the comment:

Thanks for pointing that out Serhiy. It turns out sighandler_t is non-standard. 
My latest tweak seems to have fixed things.

Also thankyou Eric for your persistence with this patch :)

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23735] Readline not adjusting width after resize with 6.3

[Roundup Robot]

Roundup Robot added the comment:

New changeset e3f375047edf by Martin Panter in branch '3.5':
Issue #23735: Avoid sighandler_t Gnu-ism
https://hg.python.org/cpython/rev/e3f375047edf

New changeset 0e576d094dc4 by Martin Panter in branch 'default':
Issue #23735: Merge sighandler_t fix from 3.5
https://hg.python.org/cpython/rev/0e576d094dc4

New changeset 596946c06a31 by Martin Panter in branch '2.7':
Issue #23735: Avoid sighandler_t Gnu-ism
https://hg.python.org/cpython/rev/596946c06a31

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23551] IDLE to provide menu link to PIP gui.

[Upendra Kumar]

Upendra Kumar added the comment:

I have one doubt about writing unittests for pip_gui. For writing the unittest 
what should I use as a test instance? For example, if we take particular pip 
package like : Flask

Now, if I have to test the 'get_data_show()' function in temp_pip_v3.py (using 
the assertXYZ functions), then I will use the output of 'pip show flask' as an 
example test case. But, it may be the case that Flask is not installed in 
others' machine. In this case the test would fail. Therefore, what should I use 
as a example test case?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21069] test_fileno of test_urllibnet intermittently fails

[STINNER Victor]

STINNER Victor added the comment:

I added a timeout because test_urllibnet fails with a timeout after 15 minutes 
on the ARM buildbot and other tests of the same file also use a timeout.

I tried but failed to reproduce the timeout.

I ran the test after my change and it passes so I considered that it was ok. I 
understand your rationale for timeout, non blocking socket and read() returning 
None.

Can we modify the test to use a selector to wait until the socket is ready and 
only read available bytes, rather than reading all data?

Using a local server would also avoid blocking too long (take less than 15 min).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23735] Readline not adjusting width after resize with 6.3

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/10490/steps/compile/logs/warnings%20%282%29

/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Modules/readline.c:939:
 warning: implicit declaration of function 'sigwinch_ohandler'

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26689] Add `has_flag` method to `distutils.CCompiler`

[SilentGhost]

Changes by SilentGhost :


--
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com