[issue30246] fix several error messages in struct
Martin Panter added the comment: FWIW a similar change to the Struct constructor message was also proposed in Issue 19985. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19985] Not so correct error message when initializing Struct with ill argument
Martin Panter added the comment: For Python 2.7, this change doesn’t seem important enough for a bug fix. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19985> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31447] proc communicate not exiting on python subprocess timeout using PIPES
Martin Panter added the comment: I’m not familiar with Windows commands or processes enough, but going by Erik’s comment, this sounds similar to Issue 26534 and Issue 30154. Doesn’t your “waitfor” command inherit the same parent process’s stdout etc pipes? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31447> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27815] Make SSL suppress_ragged_eofs default more secure
Martin Panter added the comment: Even if some use cases depend on suppress_ragged_eofs=True, I think it is best to avoid that as the default. There could be a deprecation period if necessary. I tested some HTTP clients I had handy. In summary, most seemed to handle a truncation attack on the Set-Cookie field sensibly (but Python is vulnerable without my patch or other solution). On the other hand, all the clients I tried handled one case of an insecurely-truncated body the same as a normal EOF (while I propose to treat this as an error). The clients I tested: Firefox/46.0, curl/7.43.0, Wget/1.13.4, Links 2.12, ELinks/0.13.GIT, Python-urllib/3.5 (unpatched), and Python-urllib/3.7 with my patch. I tried three test cases: 1. Truncate Set-Cookie field, with no terminating newline. The client should not accept the cookie, in case an attribute such as “Secure” was removed, like in <https://bugs.chromium.org/p/chromium/issues/detail?id=244260>. >>> c.sendall(b"Set-Cookie: COOKIE=meant-to-be-Secure") >>> c.shutdown(SHUT_RDWR) Python (unpatched) treats the Set-Cookie field as valid. It appears in the HTTPResponse object, with no clue that it was truncated. Wget was also vulnerable. Firefox and Curl did not record the cookie, but did not indicate any error either. Links does not support cookies, while Elinks tried 3 times and reported an error. 2. Content-Length response with truncated text/html. IMO a client should inform the user that the response was cut off (with or without SSL), but sometimes the user may want to see the first half of the response anyway. >>> c.sendall(b"Content-Length: 100\r\n\r\n" b"Truncat") >>> c.shutdown(SHUT_RDWR) Curl, wget, Links and Elinks all outputted the incomplete response, and reported an error. Firefox displayed the truncated page without indicating any error. In most cases, Python raised an IncompleteRead exception, but it depended on the pattern of read calls, and some or all of the truncated data was hidden in the undocumented “IncompleteRead.partial” attribute. 3. “Connection: close” response with truncated HTML: >>> c.sendall(b"Connection: close\r\n\r\n" b"Truncat") >>> c.shutdown(SHUT_RDWR) This is the case where all the clients (other than my patched Python) treated this like a valid non-truncated response. But IMO in general it should be dealt with like the Content-Length case if the SSL level wasn’t shut down properly. Victor: Sorry, I’m unlikely to make a Git Hub pull request any time soon, but I don’t mind if someone else does. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27815> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29396] Re-opening /dev/tty breaks readline
Martin Panter added the comment: I agree it would be good to document when the Readline library is invoked. Yes, the “readline” module is only designed to work with the original sys.stdin and sys.stdout. Python’s “open” function does not use FILE objects, but Python does use FILE objects internally for its Readline hook, and passes them to the Readline library. Python falls back to dumber implementations, which may not implement history nor completion, when it decides not to use Readline. The “readline” module is implemented in Modules/readline.c and uses “rl_instream” <https://cnswww.cns.cwru.edu/php/chet/readline/readline.html#IDX228> and “rl_outstream” to specify FILE objects that the Readline library uses. These FILE objects are passed through the PyOS_ReadlineFunctionPointer hook <https://docs.python.org/3.4/c-api/veryhigh.html#c.PyOS_ReadlineFunctionPointer> from the PyOS_Readline function in Parser/myreadline.c. They are required to be terminals (checked with the Posix “isatty” call). The implementation of Python’s “input” function is in the “builtin_input” C function in Python/bltinmodule.c. Before calling PyOS_Readline, it requires that sys.stdin.fileno() and sys.stdout.fileno() match the stdin and stdout FILE objects. It also does its own isatty checks. You might have some luck calling “fopen” with the “ctypes” module, or writing your own Readline module, but it wouldn’t be straightforward. You might be able to fool the check by reopening file descriptors 0 and 1, but that seems rather hacky. Or you might rely on the OS to provide history and/or completion (I think the Windows console does this in a limited way), or an external Readline wrapper program (e.g. search for “rlwrap”). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31366] Missing terminator option when using readline with socketserver.StreamRequestHandler
Martin Panter added the comment: The socket.makefile(newline=...) parameter only affects text mode, but StreamRequestHandler’s “rfile” attribute works in byte mode. You could call makefile or TextIOWrapper yourself, but neither of these options support reading null-terminated “lines” or packets. I think it would be best to implement this more generally, e.g. via Issue 1152248 or Issue 17083. Perhaps like the “asyncio.StreamReader.readuntil” or “telnetlib.Telnet.read_until” methods, rather than a stream configuration option. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29396] Re-opening /dev/tty breaks readline
Martin Panter added the comment: I think the difference between Python 2 and 3 here is that Python 2’s file objects, including sys.stdin, wrap C library FILE objects, which is supported by the Readline library. However Python 3 has its own kind of file objects, independent of standard C and Readline. Python 3 only uses Readline if sys.stdin corresponds to the original C stdin FILE object. Perhaps Python 3 could support Readline with other file objects (or at least file descriptors), but I think that would be a new feature. -- nosy: +martin.panter type: -> enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29396> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31365] Multiplication issue with 16.1
Martin Panter added the comment: The floating-point numbers are only accurate to about 16 digits. You probably just found a value that cannot be exactly represented. https://docs.python.org/3.3/faq/design.html#why-are-floating-point-calculations-so-inaccurate -- nosy: +martin.panter resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31360] argparse mutually_exclusive_group under add_argument_group fails if part of parent_processor
Martin Panter added the comment: Seems the same as two other open bugs: Issue 25882 and Issue 16807. -- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> argparse help error: arguments created by add_mutually_exclusive_group() are shown outside their parent group created by add_argument_group() ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31320] test_ssl logs a traceback
Martin Panter added the comment: Not sure if you just want to hide the presence of the exception and traceback. But regarding the exception itself (OSError with errno 0), this is not ideal. From memory, you tend to get this when the connection is shut down insecurely at the TCP level. A better exception would be SSLEOFError. Similar report in Issue 31122 (same wrap_socket → do_handshake chain). Probably also relevant: Issue 10808. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31320> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31262] Documentation Error
Martin Panter added the comment: Assuming this is about the Classes section in the tutorial, you seem to be going down the same track as <https://github.com/python/cpython/pull/2696> -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31262> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31192] "return await coro()" SyntaxError despite being "valid syntax" in PEP 492
Martin Panter added the comment:
In 3.5, “await” is an ordinary identifier outside of “async def” functions. You
have to use the “async def” syntax to enable it as a special keyword.
>>> async def foo(): # “Async def” enables “await” as a keyword
... return await coro() # Valid syntax
...
>>> async def coro(): pass
...
>>> def await(c):
... c.close() # Avoid RuntimeWarning
... return "Called await({!r})".format(c)
...
>>> def bar(): # Ordinary non-PEP-492 function
... return await (coro())
...
>>> bar()
'Called await()'
--
nosy: +martin.panter
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31192>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1732367] Document the constants in the socket module
Martin Panter added the comment: The general rule for documenting availability seems to be to only list the special cases. Many of the socket options are specified by Posix, and seem to be available on Linux, Windows, BSD and other OSes. If you say “Availability: Linux, Windows”, it could imply that the API is specific to those two platforms, and not available on Free BSD or other platforms in general. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1732367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1732367] Document the constants in the socket module
Martin Panter added the comment: Issue 13256 contains a patch documenting socket options, but was closed because the author lost interest. Issue 27409 is a proposal to list the symbols available without documenting what each one is for. -- dependencies: +Document and test new socket options, List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1732367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31158] test_pty: test_basic() fails randomly on Travis CI
Martin Panter added the comment: Checking for short writes is worthwhile, but in Issue 29070 it looks like Cornelius identified the main problem was short _reads_. See the parts of his patch to do with “_os_read_exactly” and related functions. -- nosy: +Cornelius Diekmann, martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31136] raw strings cannot end with a backslash character r'\'
Martin Panter added the comment: What would your proposal do where an embedded backslash is currently valid? >>> print(r'Backslash apostrophe: \'.') Backslash apostrophe: \'. >>> r'\' # Comment or string?' "\\' # Comment or string?" -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Martin Panter added the comment: It might help if you explained what “atrocities” are happening on your network. Is there a proxy or man-in-the-middle (or the remote peer) that shuts down TCP connections? If so, perhaps this is similar to Issue 10808. From my memory, in that case an OS “recv” or “read” call returns zero to indicate a connection was shut down. Python and/or Open SSL correctly treats this as an error, but then assumes “errno” is valid. Perhaps Python should be raising SSLEOFError in this situation. Maybe also check the “suppress_ragged_eofs” setting, but I think that only affects later stages, after the handshake succeeds. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31076] http.server should correctly handle HTTP 1.1 responses without a content-length
Martin Panter added the comment: The trouble is you would also have to parse the Transfer-Encoding field, and have special logic for responses where Content-Length is not needed or irrelevant (certain combinations of method and status code). And even then you risk breaking rare or custom methods and status codes. All this seems complex and at the wrong layer. A server shouldn’t be parsing the header fields it just generated. Perhaps there could be a new HTTP 1.1 mode (separate from protocol_version) that still closed the connection by default, but had a clearer API for keeping the connection open that the programmer can use in the right circumstances. But I had this thought before (see Issue 21224), and it didn’t seem beneficial. What’s your use case? Why not just stick with HTTP 1.0, or update the server code to either close the connection or use chunked encoding? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31076> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Martin Panter added the comment: I think chunked encoding is only meant to be used for HTTP 1.1. For HTTP 1.0, you have to either send Content-Length, or shut down the connection after sending the body. See also Issue 21224 about improving HTTP 1.1 support. Maybe you should add a “Vary: accept-encoding” field (even if gzip not acceptable to the client). I wonder if it is possible to make some of the code more generic? E.g. rather than being coupled to SimpleHTTPRequestHandler, perhaps the chunk encoder, request parsing, etc could also be usable by custom servers. We already have one chunk encoder in “http.client” and an Accept-Encoding parser in “xmlrpc.server”. FWIW I think using GzipFile should be safe if done right. You would give it a custom writer class that accepted gzip-encoded chunks, added HTTP chunk encoding (for HTTP 1.1), and sent them to the client. IMO this is a more flexible way of doing a chunk encoder. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31025] io.BytesIO: no way to get the length of the underlying buffer without copying data
Martin Panter added the comment: Can’t you use b.seek(0, SEEK_END)? -- nosy: +martin.panter versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29606] urllib FTP protocol stream injection
Martin Panter added the comment: Serhiy, that is what Dong-hee already proposed in <https://github.com/python/cpython/pull/1214>, but someone needs to decide if we want to support RFC 2640, in which I understand LF on its own is legal, and CR is escaped by adding a NUL. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30393] test_readline hangs
Martin Panter added the comment:
Thanks for the information. That narrows the problem down, but I still don’t
exactly know why it hangs.
A good workaround may be to put a timeout in the “select” call for a second or
so, and if it times out, raise an exception which will fail the test but let
the rest of the tests continue. To add the timeout, I would change the code in
“run_pty” to look like
selected = sel.select(timeout=1)
if not selected:
raise Exception("Child timed out: remaining input {!r}, output {!r}".format(
input, output))
for [_, events] in selected:
...
This is what “test_auto_history_enabled” is supposed to do:
1. Create a pseudo-terminal with master and slave file descriptors
2. Spawn a child process to read from the slave and then print the test result
to the slave
3. Parent waits to be able to read from or write to the PTY master
4. Parent writes the bytes b"dummy input\r" to the PTY
5. Child calls “input” which calls the Readline library and reads the input
6. Child writes the test result to the PTY slave
7. Parent reads the output from the child
8. Child closes its slave file descriptor and exits
9. On Linux, reading then raises EIO indicating all copies of the slave are
closed and there is no more output left to read
The parent is hanging at step 3, before entering step 4, 7, or 9. Some input
may already have been written to the child, and some output may have been
captured, but it assumes the child is still running and is waiting for it to
exit, which should close the slave file descriptor.
It would be interesting to confirm if the child has exited or is still waiting
for the CR to terminate its input line. Or perhaps the slave file descriptor
has somehow been duplicated in a third process without being closed.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27068] Add a detach() method to subprocess.Popen
Martin Panter added the comment: Personally, I haven’t needed this feature. But I still think it may be a decent solution for the “webbrowser” module, potentially your “asyncio” problem, and other cases that could now trigger an unwanted ResourceWarning. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30319] Change socket.close() to ignore ECONNRESET
Martin Panter added the comment: Thanks for handling this Victor. To answer some of your earlier questions, this is my understanding of the Free BSD behaviour (although I don't have Free BSD to experiment with): When writing to TCP sockets, I believe the data is buffered by the local OS (as well as the network, remote peer, etc). The send call will normally return straight away. In the background, the OS might combine the data with existing buffers, send it to the network, wait for acknowledgements, retransmit it, etc. On Free BSD, steps to trigger ECONNRESET might be: 1. Establish a TCP connection. 2. Send some data to the remote peer. OS returns immediately without indicating if data will successfully be sent. 3. Remote receives data packet, but decides the connection is not valid, so responds with reset message. Maybe its socket was shut down, or the OS rebooted. 4. Close the local socket. If TCP reset message was received in time, Free BSD raises ECONNRESET. I understand ECONNRESET is an _indication_ that not all pending data was delivered. But this is asynchronous, and a lack of ECONNRESET does not guarantee that all pending data was delivered. Imagine if steps 3 and 4 were swapped above. I doubt Free BSD will block the close call until the data is acknowledged, so it won't know if the peer will reset the connection in the future. To guarantee the data was delivered to the application (not just the remote OS), you do need an application-level acknowledgement. For SSL, when you call the top-level SSLSocket.close, I don't think that does much at the SSL level. Again, if you need delivery indication, I would use an app-level acknowledgement. Also beware that by default, Python doesn't report a secure EOF signal sent from the remote peer, so I think you either need a specific app-level message, or should disable the suppress_ragged_eofs mode (see Issue 27815). Antoine: sorry for abusing the dependencies list; I will try to avoid that in the future. It seemed the easiest way to get a two-way link to a bunch of other bugs that could be duplicates, but I wasn't sure at the time. My theory was if this bug was fixed, someone could review those other bugs and see if they could also be closed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19613] test_nntplib: sporadic failures, test_article_head_body()
Martin Panter added the comment: It looks like I was fairly confident about my patch, but it was all theoretical and I was never able to analyze the failure myself. Sorry but I am unlikely to spend much time on this or open a pull request any time soon. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30713] Reject newline character (U+000A) in URLs in urllib.parse
Martin Panter added the comment:
It might help if you explained why you want to make these changes. Otherwise I
have to guess. Is a compromise between strictly rejecting all non-URL
characters (not just control characters), versus leaving it up to user
applications to validate their URLs?
I guess it could partially prevent some newline injection problems like Issue
29606 (FTP) and Issue 30458 (HTTP). But how do we know it closes more security
holes than it opens?
I don’t understand the focus on these three functions. They are undocumented
and more-or-less deprecated (Issue 27485). Why not focus on the “urlsplit” and
“urlparse” functions first?
Some of the changes seem to go too far, e.g. in the
splithost("//hostname/u\nrl") test case, the hostname is fine, but it is not
recognized. This would partially conflict the patch in Issue 13359, with
proposes to percent-encode newlines after passing through “splithost”. And it
would make the URL look like a relative URL, which is a potential security hole
and reminds me of the open redirect bug report (Issue 23505).
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30713>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29926] IDLE: in shell, time.sleep ignores _thread.interrupt_main()
Martin Panter added the comment: I doubt the Gnu Readline library nor Python’s readline module are relevant. The input function only uses Readline if sys.stdin is the original stdin terminal; I suspect Idle monkey-patches sys.stdin. The readline method reads directly from the file object; it never uses the Readline library (despite the unfortunate clash in names :). Louie seems to have added two workarounds: the finish flag, and using interrupt_main with a timeout. Both seem racy. What if the flag is altered in another thread between when the flag is checked and when it is acted upon? What has to happen in the 0.2 s between calling interrupt_main and raising SIGINT? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29926> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30391] test_threading_handled() of test_socketserver hangs randomly on AMD64 FreeBSD 10.x Shared 3.6
Martin Panter added the comment: These tests are supposed to: 1. Create a TCP server 2. Open a TCP connection 3. Run a custom connection handler (depending on the particular test) in a new thread 4. When the handler returns, the new thread should call “shutdown_request” 5. Shutdown_request closes the server’s connection socket 6. Shutdown_request sets an event for the main thread 7. Main thread waits for the above event The stack trace indicates a thread is stuck at step 7. My guess is that step 5 has raised an exception, killing the thread rather than continuing to step 6. I suspect it is a “socket.close” call raising an asynchronous error such as ECONNRESET; see Issue 30319. A general fix for that problem might fix these test_socketserver hangs. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30391> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30319] ConnectionResetError: [Errno 54] Connection reset by peer in socket.close on FreeBSD, Py 3.6
Martin Panter added the comment:
I think fixing all affected calls to socket.close in the world (option 3) would
be too much. I just added two new reports (Issue 30652 and Issue 30391) as
dependencies. These are about testing socketserver.TCPServer. As an example, to
fix the socket.close call there, I think the change would look like
class TCPServer:
def close_request(self, request):
try:
request.close()
except ConnectionError:
# Suppress asynchronous errors such as ECONNRESET on Free BSD
pass
Instead of that change all over the place, I am thinking option 2 would be
safest. In Modules/socketmodule.c, something like
sock_close(PySocketSockObject *s)
{
Py_BEGIN_ALLOW_THREADS
res = SOCKETCLOSE(fd);
Py_END_ALLOW_THREADS
/* ECONNRESET can occur on Free BSD */
if (res < 0 && errno != ECONNRESET) {
return s->errorhandler();
}
}
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30319>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30319] ConnectionResetError: [Errno 54] Connection reset by peer in socket.close on FreeBSD, Py 3.6
Changes by Martin Panter <vadmium...@gmail.com>: -- dependencies: +test_threading_handled() of test_socketserver hangs randomly on AMD64 FreeBSD 10.x Shared 3.6, test_threading_not_handled() of test_socketserver hangs randomly on AMD64 FreeBSD 10.x Shared 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
Martin Panter added the comment: Don’t let my minus sign suggestion stop this, especially since a couple other people said they don’t like it. The current pull request proposal is beneficial without it. Isn’t there a “Unicode writer” API that could be used? Maybe that’s another alternative to the string accumulation or list building, but I never used it so it may not be appropriate. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30754] textwrap.dedent mishandles empty lines
Martin Panter added the comment: Some people like to avoid indented blank lines, treating them the same as trailing whitespace. I suspect this behaviour may be intentional. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30754> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Martin Panter added the comment: For existing “.gz” files, I wasn’t suggesting to compress them a second time, just for the server report that they are already compressed, like how it reports the Content-Type value based on the file name. Including Content-Encoding would help browsers display pages like <http://www.yoyodesign.org/outils/ngzip/index.en.html.gz>. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30716] Failing tests with installed 3.6.2rc1 on Win 10-64
Martin Panter added the comment: Sounds similar to Issue 27425. Did rc1 get built with mangled newlines or something? -- components: +Tests, Windows nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24465] Make shutil.make_archive have deterministic sorting
Changes by Martin Panter <vadmium...@gmail.com>: -- dependencies: +tarfile add uses random order title: Make tarfile have deterministic sorting -> Make shutil.make_archive have deterministic sorting ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue24465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Martin Panter added the comment: I think neither Pierre’s nor Glenn’s implementations should be added to SimpleHTTPRequestHandler. In fact I think most forms of content negotiation are only appropriate for a higher-level server. It seems too far removed from the intention of the class, “directly mapping the directory structure to HTTP requests”. Another concern with Pierre’s proposal is the delay and memory or disk usage that would be incurred for a large file (e.g. text/plain log file), especially with HEAD requests. I have Linux computers set up with /tmp just held in memory, no disk file system nor swap. It would be surprising that a HTTP request had to copy the entire file into memory before sending it. It may be reasonable to serve the Content-Encoding field based on the stored file though. If the client requests file “xyz”, there should be no encoding, but if the request was explicitly for “xyz.gz”, the server could add Content-Encoding. But I suspect this won’t help Pierre. Some other thoughts on the pull request: * x-gzip is supposed to be an alias in HTTP 1.1 requests * The response is HTTP 1.0, where x-gzip seems to be the canonical name * In HTTP 1.1 requests, consider supporting Accept-Encoding: gzip;q=1 * Accept-Encoding: gzip;q=0 * Accept-Encoding: * * Accept-Encoding: GZIP (case insensitivity) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30625] Documentation is unclear how "y*" and "y#" format units vary
Martin Panter added the comment: Issue 24009 proposes deprecating y# (among other units). IMO the documentation and error message aren’t specific enough regarding the reference to “bytes-like”. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30625> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18140] urlparse, urlsplit confused when password includes fragment (#), query (?)
Changes by Martin Panter <vadmium...@gmail.com>: -- dependencies: +[security] urllib connects to a wrong host ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25026] (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type commands for ioctl(2).
Martin Panter added the comment: Maybe Issue 16124 is related; it mentions 64-bit values, but it sounds like an obscure use case. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30669] json.tool does not accept an --indent flag
Martin Panter added the comment: Issue 29636 looks related -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30669> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27485] urllib.splitport -- is it official or not?
Martin Panter added the comment: I don't think it is worth changing the implementations to be in terms of urlsplit or urlparse. This is proposed for splithost in <https://github.com/python/cpython/pull/1849>, but I suspect it would change the behaviour in some corner cases. See Issue 22852 for some deficiencies with urlsplit. 3. Change existing usage to the internal _split functions, unless there is a reason (bug or security problem) to make further changes. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23019] pyexpat.errors wrongly bound to message strings instead of message codes
Martin Panter added the comment: Also, even in the Py 3 docs, the ErrorCode parser attribute is said to be numeric, but there is a suggestion to compare it with “constants” defined in the “errors” (module) object. I guess it should be clarified that you can’t compare it directly; perhaps using ErrorString or Py 3’s “errors.codes” is more appropriate? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23019> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12067] Doc: remove errors about mixed-type comparisons.
Martin Panter added the comment: Yes I think I committed all the documentation. Someone needs to decide whether to use Andy’s tests as they are, or perhaps modify or drop some or all of them. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12067> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Martin Panter added the comment: Why do you want to this? Encoding files on the fly seems out of scope of the SimpleHTTPRequestHandler class to me, but perhaps a more flexible API that could be plugged in by the user could be beneficial. See xmlrpc.server.SimpleXMLRPCRequestHandler.accept_encodings and related code for an existing implementation. Did you consider using Transfer-Encoding instead of Content-Encoding? What do you propose to do with Content-Length? What would happen to code that uses persistent HTTP connections? There are a few bugs open about this in the client: Issue 1508475 discusses handling compression (especially via Content-Encoding), and Issue 4733 talks about text decoding, which would depend on decoding the Content-Encoding first. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30315] test_ftplib.TestTLS_FTPClass: "[Errno 54] Connection reset by peer" on "AMD64 FreeBSD CURRENT Debug 3.x" buildbot
Martin Panter added the comment: See <https://bugs.python.org/issue30319#msg295109> about the “socket.close” exception, which should only affect 3.6+. But the 2.7 “recv” exception is a bit different. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30319] ConnectionResetError: [Errno 54] Connection reset by peer in socket.close on FreeBSD, Py 3.6
Martin Panter added the comment: Making this an index of related reports: Issue 30319: test_imap Issue 30315: test_ftplib Issue 30543: test_timeout Issue 30328: test_ssl Issue 27784: test_asyncore.TestAPI_UseIPv6Select.test_handle_accept, test_socketserver Issue 30106: test_asyncore.TestAPI_UseIPv6Poll.test_handle_write These all look like a side effect of my change to raise an error from the OS as an exception when closing a socket, Issue 26685. Only 3.6+ is affected. According to <https://www.freebsd.org/cgi/man.cgi?close%282%29>, ECONNRESET means “The underlying object was a stream socket that was shut down by the peer before all pending data was delivered”. It seems this is specific to Free BSD. See bug report about Posix compliance: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=159179>. According to <https://forums.zeroc.com/discussion/5569/patch-to-network-cpp-for-freebsd-for-econnreset-on-close-2-problem> this started in Free BSD 6.3 in 2006. I suppose the options are: 1. Completely revert Issue 26685 and ignore all “socket.close” errors (my least preferred option) 2. Ignore ECONNRESET in “socket.close” (backwards compatible, could use “os.close” if you really want to check for ECONNRESET) 3. Ignore ECONNRESET in the various higher-level libraries 4. Adjust the tests to ignore the error or otherwise avoid the problem -- dependencies: +Random failure of test_TCPServer() of test.test_socketserver.SocketServerTest and test_handle_accept() of test.test_asyncore.TestAPI_UseIPv6Select on FreeBSD buildbots, test_asyncore: test_handle_write() fails in tearDown(), test_ftplib.TestTLS_FTPClass: "[Errno 54] Connection reset by peer" on "AMD64 FreeBSD CURRENT Debug 3.x" buildbot, test_ssl.test_connect_with_context(): ConnectionResetError on AMD64 FreeBSD 9.x 3.6, test_timeout fails on AMD64 FreeBSD CURRENT Debug 3.x: ConnectionResetError: [Errno 54] Connection reset by peer keywords: +3.6regression nosy: +martin.panter title: test_invalid_authentication() of test_imaplib: ConnectionResetError: [Errno 54] Connection reset by peer in shutdown() on AMD64 FreeBSD 9.x 3.6 -> ConnectionResetError: [Errno 54] Connection reset by peer in socket.close on FreeBSD, Py 3.6 type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30558] [Suggestion] Improve documentation for set() API
Martin Panter added the comment: Did you see <https://docs.python.org/3.6/library/stdtypes.html#set-types-set-frozenset>? -- assignee: -> docs@python components: +Documentation nosy: +docs@python, martin.panter status: open -> pending ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] CRLF Injection in httplib
Martin Panter added the comment:
You can also inject proper HTTP header fields (or do multiple requests) if you
omit the space after the CRLF:
urlopen("http://localhost:8000/ HTTP/1.1\r\nHEADER: INJECTED\r\nIgnore:")
Data sent to the server:
>>> server = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
>>> server.bind(("localhost", 8000))
>>> server.listen()
>>> [conn, addr] = server.accept()
>>> pprint(conn.recv(300).splitlines(keepends=True))
[b'GET / HTTP/1.1\r\n',
b'HEADER: INJECTED\r\n',
b'Ignore: HTTP/1.1\r\n',
b'Accept-Encoding: identity\r\n',
b'User-Agent: Python-urllib/3.5\r\n',
b'Connection: close\r\n',
b'Host: localhost:8000\r\n',
b'\r\n']
Issue 14826 is already open about how “urlopen” handles spaces, and there is a
patch in Issue 13359 that proposes to also encode newline characters. But if
the CRLF or header injection is a security problem, then 2.7 etc could be
changed to raise an exception (like Issue 22928), or to do percent encoding.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30458>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13359] urllib2 doesn't escape spaces in http requests
Martin Panter added the comment: I think this could be merged with Issue 14826. Maybe it is sensible to handle all control characters the same way. -- nosy: +martin.panter resolution: -> duplicate superseder: -> urlopen URL with unescaped space ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30516] Documentation for datetime substract operation incorrect?
Martin Panter added the comment:
The C "_datetime" implementation seems to handle this as documented. But either
way, the "timedelta" range is greater than the "datetime" range, so it seems to
be just a difference in OverflowError messages, not a big practical problem:
Python "datetime" implementation:
>>> import sys
>>> sys.modules["_datetime"] = None
>>> from datetime import *
>>> datetime.max - timedelta.max
Traceback (most recent call last):
File "", line 1, in
File
"C:\Users\Martin\AppData\Local\Programs\Python\Python35-32\lib\datetime.py",
line 1741, in __sub__
return self + -other
File
"C:\Users\Martin\AppData\Local\Programs\Python\Python35-32\lib\datetime.py",
line 518, in __neg__
-self._microseconds)
File
"C:\Users\Martin\AppData\Local\Programs\Python\Python35-32\lib\datetime.py",
line 430, in __new__
raise OverflowError("timedelta # of days is too large: %d" % d)
OverflowError: timedelta # of days is too large: -10
C "_datetime" implementation:
>>> from datetime import *
>>> datetime.max - timedelta.max
Traceback (most recent call last):
File "", line 1, in
OverflowError: date value out of range
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30516>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29596] Unfinished sentence in howto/clinic.rst
Martin Panter added the comment: Currently for the “buffer” destination, it says Suppress . . ., write . . . to ``block``, and write everything else to ``file``. Would it be more correct to change “file“ to “buffer”? I.e. Suppress . . ., write . . . to ``block``, and write everything else to ``buffer``. -- components: +Argument Clinic nosy: +martin.panter stage: needs patch -> patch review title: Unfinished sentense in howto/clinic.rst -> Unfinished sentence in howto/clinic.rst ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30500] urllib connects to a wrong host
Martin Panter added the comment: See also Issue 18140, where it looks like people _want_ the hash (#) to be part of the username and/or password. Another option may be to raise an exception. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7
Martin Panter added the comment: I think the simplest way forward would be to add the word “Unicode” back in. You could look at making a Git Hub pull request for this if you want. Hopefully somebody else can merge it though, because I probably won’t be in a position to do so for a while. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30393] test_readline hangs
Martin Panter added the comment: Perhaps if you ran the tests in verbose mode, that could narrow down which test it hangs at. Also, if you can capture a KeyboardInterrupt stack trace, that may help. Not sure if it works with your build setup, but maybe you can run something like ./python -m unittest -v test.test_readline Not too long ago, I added some tests that run a child process in a pseudoterminal (see the “run_pty” function). There were a few platform specific problems getting that working, so there is a good chance your problem may be related. I wonder if test hangs when you don’t use “--enable-optimizations”? -- nosy: +martin.panter stage: -> test needed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30476] Add _GenerateCRCTable() to zipfile.py to pre-compute CRC Table
Changes by Martin Panter <vadmium...@gmail.com>: -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30476> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30477] tuple.index error message improvement
Martin Panter added the comment: Also discussed in Issue 13349 -- nosy: +martin.panter superseder: -> Non-informative error message in index() and remove() functions ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30477> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30441] os.environ raises RuntimeError: dictionary changed size during iteration
Martin Panter added the comment: Previous report: Issue 25641. At least in Posix, the “putenv” function is not required to be thread safe. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30437] SSL_shutdown can return meaningless SSL_ERROR_SYSCALL
Martin Panter added the comment: Maybe Issue 10808? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30437> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29321] Wrong documentation (Language Ref) for unicode and str comparison
Martin Panter added the comment: I backported Issue 12067 documentation, so hopefully this is fixed. -- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> Doc: remove errors about mixed-type comparisons. ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30435] Documentation either unclear or incorrect on comparisons between bytes and strings in Python 3
Martin Panter added the comment: Also, “-bb” turns it into an exception, and the same applies to bytes vs int: >>> b"a" == "a" Traceback (most recent call last): File "", line 1, in BytesWarning: Comparison between bytes and string >>> b"a" == 0x61 Traceback (most recent call last): File "", line 1, in BytesWarning: Comparison between bytes and int Perhaps the documentation should say “should not be compared” rather than “cannot”. Or perhaps it should mention “-b”. Mariatta: I don’t think this is relevant to 2.7. In 2.7, you do get an error with bytearray vs unicode, but bytearray is not discussed in this bit of the Py 2 documentation. -- nosy: +Mariatta, martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30420] Clarify kwarg handing for subprocess convenience APIs
Martin Panter added the comment: If you add “cwd” to Frequently Use Arguments, please try to keep the details in one place. Otherwise you encourage a fix for Issue 15533 (cwd platform specifics) to repeat the problem of Issue 20344 (args vs shell platform specifics), where some details are only found in one section and contradict the other section. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30420] Clarify kwarg handing for subprocess convenience APIs
Martin Panter added the comment: For the curious, Nick added the “frequently used arguments” in Issue 13237. Before that the signatures were like <https://docs.python.org/release/3.2.2/library/subprocess.html#convenience-functions>: subprocess.call(*popenargs, **kwargs) -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30420> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
Martin Panter added the comment: I think the benefit of the repr being easier to understand outweighs the pain of breaking the old format. If the change is a problem, that might be mitigated by adding an entry to the “Porting to Python 3.7” documentation. I don’t think my option of factoring the minus sign out to the front of the timedelta constructor was mentioned on Python-dev. The advantage is that it doesn’t mention problematic negative attribute values, and if you negate a timedelta, you still get the right attribute values: >>> d -datetime.timedelta(seconds=60) >>> -d datetime.timedelta(seconds=60) >>> (-d).seconds 60 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23674] super() documentation isn't very clear
Martin Panter added the comment: Cheryl: see also Issue 25777 and Issue 20751, both about the “super binding” under Invoking Descriptors. Raymond: if you want to just pick parts of my patch, go for it. But I don’t understand your concern about explaining the MRO. I think it is important to explain which base classes are skipped, and which are searched. It is not just the type/subclass (super.__thisclass__) entry in the MRO that is skipped; this parameter determines the starting point, so the preceding entries are also skipped. Another problem with referring to “getattr” is that it checks for instance attributes and custom __getattr__ and __getattribute__ implementations, but I don’t think “super” does any of that. Looking at my patch now, I would propose that the exception message only be changed in the current (3.7) branch. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23674> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20751] Misleading descriptor protocol documentation: direct call, super binding
Martin Panter added the comment: Lower-case “a” is defined at the top of the list: “The starting point . . . is ‘a.x’.” The last entry may fit in better if it was written “If binding to an instance of ‘super’ ”. The problem with the m() call is also mentioned in Issue 25777, about the descriptor how-to. Issue 12077 seems to be largely about the __get__ signature. -- dependencies: +Harmonizing descriptor protocol documentation nosy: +martin.panter, rhettinger stage: -> needs patch title: Misleading examples in the descriptor protocol documentation -> Misleading descriptor protocol documentation: direct call, super binding versions: +Python 2.7, Python 3.6, Python 3.7 -Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29854] Segfault when readline history is more then 2 * history size
Martin Panter added the comment: I suspect the test won’t be effective with Editline (either fail, or silently pass without testing the bug). From memory Editline uses an ~/.editrc file, not INPUTRC, with different syntax and configuration. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29854> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29619] st_ino (unsigned long long) is casted to long long in posixmodule.c:_pystat_fromstructstat
Martin Panter added the comment: What is the advantage of compiling calls to both Long and LongLong converters? Isn’t it simpler to blindly call PyLong_FromUnsignedLongLong or similar? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29619> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30324] Error using newline='' when writing to CSV file
Martin Panter added the comment: On Python 2, I'm guessing you are getting extra CRs on Windows? It looks like you have to open in binary mode there to avoid newline translation. This is documented for the "reader" and "writer" functions. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30324] Error using newline='' when writing to CSV file
Martin Panter added the comment: In Python 2, the "open" function doesn't have a "newline" parameter. Perhaps you were looking at the wrong documentation version. -- nosy: +martin.panter resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30311] random.shuffle pointlessly shuffles dicts
Martin Panter added the comment:
It is also pointless to shuffle a list object repeating the same item, but that
is no reason to add a special case. Is there a real problem with allowing
dictionaries and OrderedDict? It seems to behave sensibly if you give each item
a unique value:
>>> D = {i: i * 100 for i in range(5)}
>>> D
{0: 0, 1: 100, 2: 200, 3: 300, 4: 400}
>>> shuffle(D)
>>> D
{0: 300, 1: 100, 2: 200, 3: 0, 4: 400}
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30311>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
Martin Panter added the comment:
I understand hash randomization was added after this bug was opened. Here is a
demonstration with “video/mp4”, which only has the extension “.mp4” built in.
But my /etc/mime.types file lists “mp4 mp4v mpg4”, so after the second
initialization the behaviour changes:
PYTHONHASHSEED=0 python3.5 -c 'from mimetypes import *;
print(guess_all_extensions("video/mp4")); init();
print(guess_all_extensions("video/mp4"))'
['.mp4', '.mp4v', '.mpg4']
['.mpg4', '.mp4', '.mp4v']
The first extension is always “.mp4”, regardless of hash randomization, due to
the built-in list. But after re-initialization, the first extension depends on
the order in the internal dictionary.
Using an ordered dictionary may work as a bug fix, but the whole initialization
logic is so complex and it would be good to simplify it in the long term.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4963>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4963] mimetypes.guess_extension result changes after mimetypes.init()
Martin Panter added the comment:
I suggest to discuss the non-determinism problem in Issue 1043134 (about
determining a canonical extension for each content type). I understood this bug
(Issue 4963) is about the behaviour of repeated initialization of the same
instance of mimetypes.
BTW an ordered dictionary wouldn’t help with duplicate dictionary keys; see
guess_extension("application/excel").
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue4963>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29823] mimetypes guesses XSL mimetype when passed an XML file
Changes by Martin Panter <vadmium...@gmail.com>: -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30304] TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7
New submission from Martin Panter: In Mercurial revision 6e5b5d1b6714, the documentation for “assertMultiLineEqual” was changed from This method is used by default when comparing Unicode strings with “assertEqual”. to This method is used by default when comparing strings with “assertEqual”. The new text is misleading because “str” objects are also strings, but the default does not apply to “str” objects. -- assignee: docs@python components: Documentation, Tests keywords: easy messages: 293229 nosy: docs@python, ezio.melotti, martin.panter priority: normal severity: normal stage: needs patch status: open title: TestCase.assertMultiLineEqual only registered for Unicode strings in 2.7 type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30302] Improve .__repr__ implementation for datetime.timedelta
Martin Panter added the comment: This was discussed fairly recently: <https://marc.info/?i=captjjmrbxpvyquyxshbc1j13m_h5or67cnbkrkysw4ef6rq...@mail.gmail.com>. There seems to be a bit of support for changing this. It is not a bug fix, so has to go into the next release, now 3.7. I disagree that the positional timedelta parameters are well-known. The built-in help was also discussed in that thread. I don’t think it got fixed yet, did it? The datetime class represents absolute dates. It is nonsense to specify a date without a year. Timedelta is different, because time is measured with different units. The first parameter (days) is surprising considering most other Python APIs (sleep etc) deal with seconds. The size of the repr could be reduced a bit by dropping the module name: datetime.timedelta vs just timedelta. Although that would be inconsistent with the other classes; I’m not sure about this. Other improvements that I would like to see: 1. Drop leading zeros: timedelta(seconds=60) rather than timedelta(days=0, seconds=60). This would also help reduce the size. 2. Factor out the negative sign: -timedelta(seconds=60) rather than timedelta(days=-1, seconds=86340). -- nosy: +martin.panter title: Improve .__repr__ implementation for datetime.datetime.timedelta -> Improve .__repr__ implementation for datetime.timedelta versions: -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30097] Command-line option to suppress "from None" for debugging
Martin Panter added the comment:
This proposal would be useful. My use case is for when an API suppresses an
external exception context:
>>> import os
>>> try:
... os.environ["NEW_VARIABLE"] = bug # Hidden exception
... finally:
... del os.environ["NEW_VARIABLE"] # KeyError
...
Traceback (most recent call last):
File "", line 4, in
File "/usr/lib/python3.5/os.py", line 699, in __delitem__
raise KeyError(key) from None
KeyError: 'NEW_VARIABLE'
This feels like a step backwards to Python 2, and enabling the full backtrace
would make this easier to analyze:
>>> try:
... os.environ["NEW_VARIABLE"] = bug # TypeError
... finally:
... del dict()["NEW_VARIABLE"] # KeyError
...
Traceback (most recent call last):
File "", line 2, in
File "/usr/lib/python3.5/os.py", line 688, in __setitem__
value = self.encodevalue(value)
File "/usr/lib/python3.5/os.py", line 756, in encode
raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not object
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 4, in
KeyError: 'NEW_VARIABLE'
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30097>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25435] Wrong function calls and referring to not removed concepts in descriptor HowTo (documentation)
Martin Panter added the comment: Raymond I suggest you unassign this and let others work on it. -- stage: patch review -> needs patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30292] Why is there a concept "unbound method" in python3 version?
Changes by Martin Panter <vadmium...@gmail.com>: -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> docs.python.org/3/howto/descriptor.html still refers to "unbound methods" ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12077] Harmonizing descriptor protocol documentation
Martin Panter added the comment: See Issue 23702 specifically about unbound methods in Python 3, and Issue 25435 about general problems with the how-to in Python 3. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12077> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4755] Add function to get common path prefix
Martin Panter added the comment: Issue 10395 added “os.path.commonpath” in 3.5. -- nosy: +martin.panter resolution: -> duplicate stage: patch review -> resolved status: languishing -> closed superseder: -> new os.path function to extract common prefix based on path components ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28149] Incorrect indentation under “else” in _bsddb.c
Changes by Martin Panter <vadmium...@gmail.com>: -- resolution: -> duplicate stage: test needed -> resolved status: open -> closed superseder: -> _bsddb: else misleadingly indented ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21790] Change blocksize in http.client to the value of resource.getpagesize
Martin Panter added the comment: For plain-text (non-SSL) HTTP uploads, perhaps using “socket.sendfile” would help: Issue 13559. Another idea would be to expose and document the low-level socket (or SSL wrapper) and let the user copy data with whatever chunk size they desire. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30145] Create a How to or Tutorial documentation for asyncio
Martin Panter added the comment: See Issue 27579, where Victor wanted to focus on <https://github.com/asyncio-doc/asyncio-doc> outside of Python. -- nosy: +haypo, martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15346] Tkinter extention modules have no documentation
Changes by Martin Panter <vadmium...@gmail.com>: -- dependencies: +No Documentation on tkinter dnd module ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30119] (ftplib) A remote attacker could possibly attack by containing the newline characters
Martin Panter added the comment: I suggest to close this as a duplicate. The pull request itself looks like the right direction to me, but let’s not split the discussion up more than necessary. -- nosy: +martin.panter resolution: -> duplicate superseder: -> urllib FTP protocol stream injection ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30119> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30204] socket.setblocking(0) changes socket.type
Martin Panter added the comment: Is this a duplicate of Issue 21327? There is some discussion there and a patch to add get_socket_type that excludes SOCK_NONBLOCK. -- nosy: +martin.panter superseder: -> socket.type value changes after using settimeout() ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30204> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29606] urllib FTP protocol stream injection
Martin Panter added the comment: I think changing FTPHandler may be more appropriate than urlsplit. But I thought your other pull request <https://github.com/python/cpython/pull/1214> in “ftplib” might be enough. Or are you trying to make it more user-friendly? Also, FTPHandler is not used by URLopener and the Python 2 “urllib” module as far as I know, so on its own just fixing FTPHandler wouldn’t be enough. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30103] uu package uses old encoding
Martin Panter added the comment: I think I would prefer b2a_uu(data, grave=True), but am also happy with Xiang’s backtick=True if others prefer that. :) In my mind “grave accent” is the pure ASCII character; it just got abused for other things. Other options: b2a_uu(data, space=False) b2a_uu(data, avoid_spaces=True) b2a_uu(data, use_0x60=True) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21071] struct.Struct.format is bytes, but should be str
Martin Panter added the comment: I don’t think the API should be expanded to accept arbitrary bytes-like objects as format strings. Struct formats are strings of ASCII-compatible characters, but not arbitrary chunks of memory. I think the main question is whether it is okay to break compatibility (Victor’s pull request, or my format-str.patch), or whether there has to be a backwards-compatible deprecation of the existing bytes attribute. FWIW I am okay with breaking compatibility, since the main documentation already implies it should be a text string. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21071> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16349] Document whether it's safe to use bytes for struct format string
Changes by Martin Panter <vadmium...@gmail.com>: -- dependencies: +struct.Struct.format is bytes, but should be str -Document whether it's safe to use bytes for struct format string ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16349] Document whether it's safe to use bytes for struct format string
Martin Panter added the comment: I think the direction to take for this depends on the outcome of Issue 21071. First we have to decide if the “format” attribute is blessed as a byte string (and not deprecated), or whether it is deprecated or changed to a text string. Serhiy pointed out that it is not entirely “safe” because mixing equivalent byte and text formats can generate ByteWarning. -- dependencies: +Document whether it's safe to use bytes for struct format string ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29606] urllib FTP protocol stream injection
Martin Panter added the comment: I understand this bug (as reported by ECBFTW) is about Python injecting unexpected FTP commands when the “urllib” and “urllib2” modules are used. The “httplib” module (“http.client” in Python 3) is unaffected. I only mentioned HTTP as an example of a similar fix made recently; sorry if that was confusing. To be clear, in Python 2 I think both the “urllib” _and_ “urllib2” modules are affected, as well as “ftplib” directly. In Python 3, “urllib.request” and “ftplib” are affected. But I don’t think “urlparse” and “urllib.parse” should be changed. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30103] uu package uses old encoding
Martin Panter added the comment: FWIW I am using NXP LPC microcontrollers at the moment, whose bootloader uses the grave/backtick instead of spaces. (NXP application note AN11229.) Although in practice it does seem to accept Python's spaces instead of graves. I wouldn't put too much weight to Wikipedia, especially where it says graves are not used for encoded data (vs length and padding). Earlier versions of Wikipedia did mention graves in regular data. I understand the reason for avoiding spaces is to due to spaces being stripped (e.g. by email, copy and paste, etc). You have to avoid spaces in data, not just padding, because a data space may still appear at the end of a line. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30160] BaseHTTPRequestHandler.wfile: supported usage unclear
Martin Panter added the comment: The “Proper adherence” sentence has always bothered me. Why does “wfile” have to adhere, but not other other APIs (rfile, send_header, etc)? I wonder if the sentence is useful at all. (Of course you have to use HTTP to operate with HTTP clients.) Perhaps it was intended to say that socket-level HTTP is written to wfile, that it is up to the caller to ensure the encoding, content length, etc is consistent with the HTTP header, and/or the caller has to supply the header (either direct through wfile or via send_header etc). A plausable alternative would be a higher-level file object like the request body in “http.client”, where encoding and content length is handled by the library. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30160> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29606] urllib FTP protocol stream injection
Martin Panter added the comment: Isn’t Issue 30119 a duplicate of this? In that bug Dong-hee you posted a pull request that changes the “ftplib” module, which makes more sense to me than adding a special case to “urlsplit” that understands FTP. See how this was addressed for HTTP in Issue 22928. -- nosy: +martin.panter stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of "char *"
Changes by Martin Panter <vadmium...@gmail.com>: -- nosy: -martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28769> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26534] subprocess.check_output with shell=True ignores the timeout
Martin Panter added the comment: Issue 5115 is already open with patch that has an alternative API to the low-level “killpg” method. It also has a Windows implementation and tests. I suggest to focus this bug on the higher-level “kill_group” option. -- dependencies: +Extend subprocess.kill to be able to kill process groups ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30154] subprocess.run with stderr connected to a pipe won't timeout when killing a never-ending shell commanad
Martin Panter added the comment: This is similar to the problem described in Issue 26534, which proposes “kill_group” and “killpg” APIs as a solution. (FYI you should put a shebang at the start of the shell script, or call it as “sh -c test.sh”, to fix the “Exec format error”.) -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26534] subprocess.check_output with shell=True ignores the timeout
Martin Panter added the comment: I don’t know enough about process groups and sessions to properly review, but some things that stand out: * Patch is missing documentation and tests * If the “killpg” just wraps os.killpg, perhaps adding the method is not justified * Are there any race conditions with killing a process group that has already exited. When does a process group get freed and potentially reused (so you may kill the wrong group)? The “send_signal” method (and others) have a check to avoid signalling an unrelated process. * The method is called killpg, and the doc string mentions SIGKILL, but the implementation says SIGTERM * What happens if you use killpg without starting a new session? If it kills the parent process as well, that sounds like a source of subtle bugs that may only be detected in unexpected cases (e.g. Ctrl+C or timeout) * Be aware of Issue 25942. It is not clear what should happen to the child process(es) when the timeout happens, or when the “communicate” call is interrupted. * What platforms does this support and what happens if there is no platform support? -- nosy: +martin.panter stage: -> patch review type: behavior -> enhancement versions: +Python 3.7 -Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23404] 'make touch' does not work with git clones of the source repository
Martin Panter added the comment: A while ago I wrote a patch targetting Issue 22359 that may be a starting point for “make regen”: <https://bugs.python.org/file42169/separate-regen.patch>. It pulled out three recipes into separate “phony” targets: “make graminit importlib importlib_external”. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23404> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
