[issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
Cyril Martin <mcool...@gmail.com> added the comment: Hi Stéphane, I ask you a question about the change you suggest. The PR has not progress. Do you wait something from me? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32732> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32867] argparse assertion failure with multiline metavars
Martin Panter <vadmium...@gmail.com> added the comment: This looks like the same assertion failure as described in Issue 16360. Paul pointed to a patch in Issue 11874, so that may also be relevant. However I agree that embedding newlines in a metavar doesn’t make much sense. What’s the use case? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32867> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32875] Add __exit__() method to event loops
Martin Panter <vadmium...@gmail.com> added the comment: Maybe already discussed in Issue 24795? -- nosy: +martin.panter superseder: -> Make event loops with statement context managers ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32732] LoggingAdapter ignores extra kwargs of Logger#log()
New submission from Cyril Martin <mcool...@gmail.com>: - LoggerAdapter processes only extra kwargs given during its __init__ So extra kwargs, given to Logger#log are ignored when we configure a LoggerAdapter (same for: debug, info, warning etc). - I expect extras are merged. More precisely, I expect local extra override the ones given in __init__ -- components: Library (Lib) messages: 311353 nosy: mcoolive priority: normal pull_requests: 5289 severity: normal status: open title: LoggingAdapter ignores extra kwargs of Logger#log() versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32732> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Martin Panter <vadmium...@gmail.com> added the comment: Your assumption about calling “file_actions_destroy” would be okay if the posix_spawn_file_actions_t object was a simple object or structure. But I imagine most implementations would allocate memory when you call one of the “add” methods. Especially “addopen”, which is supposed to copy the filename string somewhere. Looking at “uclibc” <https://repo.or.cz/uclibc-ng.git/blob/v1.0.28:/include/spawn.h#l263>, I see it calls “free”, because it allocates an array for all the file actions. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Martin Panter <vadmium...@gmail.com> added the comment: TypeError if “posix_spawn_file_actions_init” fails doesn’t seem right. I suggest OSError, MemoryError, or even plain Exception instead. “File_actionsp” is set to point to a local variable “_file_actions”, but the variable goes out of scope before the pointer is used. This is technically undefined behaviour (even if it happens to work). Simplest solution would be to move the variables into the same outer scope. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Martin Panter <vadmium...@gmail.com> added the comment: Does the PySequence_Fast result need releasing if the following “for” loop fails? There is a Py_DECREF only in the successful case, which seems inconsistent. Does Python still support non-UTF-8 locales and bytes filenames? I haven’t been keeping up, but I assumed these things were still supported in many cases. It seems strange to only support UTF-8 in the “addopen” file action. Pablo’s second PR currently <https://github.com/python/cpython/pull/5418/commits/e50bdb9> calls PyErr_SetString(PyExc_OSError, . . .) with a custom error message depending on which OS call failed. But I wonder if it is more important to set the “errno” attribute (which I think should choose an OSError subclass if appropriate). Perhaps you can do that by assigning the return values to “errno” and then calling PyErr_SetFromErrno. A disadvantage might be less context about which stage went wrong. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20104] expose posix_spawn(p)
Martin Panter <vadmium...@gmail.com> added the comment: Pablo’s code looked unfinished to me. As well as missing documentation, I suspect there may be memory leaks and poor error handling. The two calls above the “fail:” label look like dead code. The “parse_envlist” result appears to be leaked. I’m curious why you never call “posix_spawn_file_actions_destroy”. I saw on Open BSD <https://man.openbsd.org/posix_spawn_file_actions_init.3> it reclaims memory, and it seems sensible to call it on other platforms as well. No error checking on any of the “posix_spawn_file_actions_” methods. If “posix_spawn” fails, the “pid” variable will be returned uninitialized. -- nosy: +martin.panter, pablogsal ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20104> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32698] Improper gzip compression if output file extension is not "gz"
Martin Panter <vadmium...@gmail.com> added the comment:
According to the documentation, you can use the lower-level GzipFile
constructor’s “filename” argument:
>>> with open(output_path, 'wb') as f_out, \
... gzip.GzipFile(fileobj=f_out, mode='wb', filename=input_path) as f_out, \
... open(input_path, 'rb') as f_in:
... shutil.copyfileobj(f_in, f_out)
...
>>> import os
>>> os.system("7z l test.txt.gzip")
[. . .]
Date TimeAttr Size Compressed Name
--- -
2018-01-28 22:23:16 . 30 34 test.txt
--- -
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32698>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32673] update tutorial dict part to reflect dict is ordered
Martin Panter <vadmium...@gmail.com> added the comment: See Issue 32337 -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32668] deepcopy() fails on ArgumentParser instances
New submission from Martin Kolman <mkol...@redhat.com>: We (the Anaconda OS intaller team) are in the process of switching to a new version of a library (Pykickstart), which among other things switched from using optparse to argparse. And during this endeavour we found that it's apparently not possible to deepcopy ArgumentParser instances: $ ipython3 Python 3.6.3 (default, Oct 9 2017, 12:07:10) Type 'copyright', 'credits' or 'license' for more information IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help. In [1]: import argparse In [2]: from copy import deepcopy In [3]: parser = argparse.ArgumentParser() In [4]: deepcopy(parser) --- TypeError Traceback (most recent call last) in () > 1 deepcopy(parser) /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 178 y = x 179 else: --> 180 y = _reconstruct(x, memo, *rv) 181 182 # If is its own copy, don't memoize. /usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy) 278 if state is not None: 279 if deep: --> 280 state = deepcopy(state, memo) 281 if hasattr(y, '__setstate__'): 282 y.__setstate__(state) /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 148 copier = _deepcopy_dispatch.get(cls) 149 if copier: --> 150 y = copier(x, memo) 151 else: 152 try: /usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy) 238 memo[id(x)] = y 239 for key, value in x.items(): --> 240 y[deepcopy(key, memo)] = deepcopy(value, memo) 241 return y 242 d[dict] = _deepcopy_dict /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 148 copier = _deepcopy_dispatch.get(cls) 149 if copier: --> 150 y = copier(x, memo) 151 else: 152 try: /usr/lib64/python3.6/copy.py in _deepcopy_list(x, memo, deepcopy) 213 append = y.append 214 for a in x: --> 215 append(deepcopy(a, memo)) 216 return y 217 d[list] = _deepcopy_list /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 178 y = x 179 else: --> 180 y = _reconstruct(x, memo, *rv) 181 182 # If is its own copy, don't memoize. /usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy) 278 if state is not None: 279 if deep: --> 280 state = deepcopy(state, memo) 281 if hasattr(y, '__setstate__'): 282 y.__setstate__(state) /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 148 copier = _deepcopy_dispatch.get(cls) 149 if copier: --> 150 y = copier(x, memo) 151 else: 152 try: /usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy) 238 memo[id(x)] = y 239 for key, value in x.items(): --> 240 y[deepcopy(key, memo)] = deepcopy(value, memo) 241 return y 242 d[dict] = _deepcopy_dict /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 178 y = x 179 else: --> 180 y = _reconstruct(x, memo, *rv) 181 182 # If is its own copy, don't memoize. /usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy) 278 if state is not None: 279 if deep: --> 280 state = deepcopy(state, memo) 281 if hasattr(y, '__setstate__'): 282 y.__setstate__(state) /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 148 copier = _deepcopy_dispatch.get(cls) 149 if copier: --> 150 y = copier(x, memo) 151 else: 152 try: /usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy) 238 memo[id(x)] = y 239 for key, value in x.items(): --> 240 y[deepcopy(key, memo)] = deepcopy(value, memo) 241 return y 242 d[dict] = _deepcopy_dict /usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil) 159 copier = getattr(x, "__deepcopy__", None) 160 if copier: --> 161 y = copier(memo) 162 else: 163 reductor = dispatch_table.get(cls) TypeError: cannot deepcopy this pattern object This should either be fixed or documented in proper places (the argparse documentation does not mention any pottential deepcopy issues as far as we can tell). -- components: Library (Lib) messages: 310686 nosy: mkolman priority: normal severity: normal status: open title: deepcopy() fa
[issue32634] Message parsing fails where it has incompele headers
Martin Panter <vadmium...@gmail.com> added the comment: Looks like a dupe of Issue 27321 -- nosy: +martin.panter resolution: -> duplicate superseder: -> Email parser creates a message object that can't be flattened ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26175] Fully implement IOBase abstract on SpooledTemporaryFile
Martin Panter <vadmium...@gmail.com> added the comment: It may also be worth implementing BufferedIOBase and TextIOBase. (It seems buffering=0 isn’t reliable, e.g. rollover with limited disk space, so it may not be worth implementing RawIOBase.) To implement BufferedIOBase, “read1” and “readinto1” should be added. To implement TextIOBase, “errors” should be added, and “newlines” should only list translated newlines, not the “newline” constructor argument. Technically, “detach” should also be implemented, although it doesn’t have to do anything useful. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26175> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32600] SpooledTemporaryFile should implement IOBase
Martin Panter <vadmium...@gmail.com> added the comment: There is apparently some work done on this already in Issue 26175. -- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> Fully implement IOBase abstract on SpooledTemporaryFile ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32600> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32561] Add API to io objects for non-blocking reads/writes
Change by Martin Panter <vadmium...@gmail.com>: -- dependencies: +Add ability to query number of buffered bytes available on buffered I/O ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32561] Add API to io objects for non-blocking reads/writes
Martin Panter <vadmium...@gmail.com> added the comment: BufferedIOBase is an abstract class and, despite the name, doesn’t necessitate a buffer or cache. Adding methods and properties might break compatibility with third-party implementations, or get ugly with optional methods and multiple versions of the API. It seems like it would be better to extend the concrete APIs: io.BufferedReader, BufferedWriter and/or FileIO. In Issue 32475 there is a proposal to add a “getbuffn” method returning the amount of unread pending data in a reader object. Perhaps that would be enough for reading. I would support an similar API for BufferedWriter etc. Perhaps a property called “available_space”. You could check that and decide whether to do a direct non-blocking “write”, or launch a blocking “write” in the background. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32475] Add ability to query number of buffered bytes available on buffered I/O
Martin Panter <vadmium...@gmail.com> added the comment: If I remember the implementation of “peek” right, it may do what you want. But the documentation doesn’t guarantee much about its behaviour; see Issue 5811. Anyway, I agree that a “getbuffn” method (or property) would be nice. (Perhaps with a better name!) But please don’t add it to the abstract APIs like BufferedIOBase. It could break compatibility with third-party implementations, or make the API complicated with little benefit. Just extend the concrete APIs like BufferedReader. Two other use cases where the “peek” implementation won’t help, but “getbuffn” would: 1. Issue 32561: Decide whether a non-blocking “read” call is possible, or if a background read (e.g. of a regular “disk” file) should be started instead. 2. Get the pending unread data before it is lost by calling ”BufferedReader.detach”. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32537] multiprocessing.pool.Pool.starmap_async - wrong parameter name
Martin Panter <vadmium...@gmail.com> added the comment: This was supposed to be fixed in 3.6+ by Issue 31304. In general, 3.5 only gets security fixes at this stage. I’m not sure if it is easy or worth back porting this. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32529] Call readinto in shutil.copyfileobj
Martin Panter <vadmium...@gmail.com> added the comment: Looks like you want to use a "readinto" method to reduce data copying. One problem is that it is not specified exactly what kind of object "copyfileobj" supports reading from. The documentation only says "file-like". According to the glossary, this means io.RawIOBase, BufferedIOBase, or TextIOBase. However TextIOBase doesn't have a "readinto" method. And it wouldn't be hard to find that someone has written their own class that doesn't have "readinto" either. The other problem is you still need to support a negative "length" value, which is easier to do by calling "read". -- nosy: +martin.panter title: improved shutil.py function -> Call readinto in shutil.copyfileobj ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32518] HTTPServer can't deal with persistent connection properly
Change by Martin Panter <vadmium...@gmail.com>: -- superseder: HTTPServer can't deal with persistent connection properly -> http.server and SimpleHTTPServer hang after a few requests ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32518] HTTPServer can't deal with persistent connection properly
Martin Panter <vadmium...@gmail.com> added the comment: Perhaps this can be treated as a duplicate of Issue 31639. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32430] Simplify Modules/Setup{,.dist,.local}
Martin Panter <vadmium...@gmail.com> added the comment: FWIW there was documentation in the README about the Setup files, removed in Subversion r57681 (= Git revision 1c896e3). It looks like it still survives in the 2.7 version. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32430> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25095] test_httpservers hangs since Python 3.5
Martin Panter <vadmium...@gmail.com> added the comment: Thanks, although the fact that “Content-Length: 0” doesn’t work kills my theory about the proxy. The “close_connection” flag is also a documented public API of Python: <https://docs.python.org/3/library/http.server.html#http.server.BaseHTTPRequestHandler.close_connection>. According to the rules for framing the message body in <https://tools.ietf.org/html/rfc7230#section-3.3.3>, the presence of “Connection: close” is not important. The server actually shutting down the connection is the key. That is why I prefer to explicitly set the flag (if it works). Anyway, your current proposal makes the server send a valid full HTTP response. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25095] test_httpservers hangs since Python 3.5
Martin Panter <vadmium...@gmail.com> added the comment:
Sorry William, I forgot the client was waiting to read. But I don’t understand
why your Connection field (which comes after the status line) allows the Python
client to read the status line. Perhaps there is some malware scanner,
firewall, or other proxy that intercepts the HTTP protocol? (I encountered
something similar at work recently.)
You said “my suggestion will never work”, but did you try setting
“close_connection” on its own:
def do_GET(self):
self.send_response(HTTPStatus.OK)
self.end_headers()
self.close_connection = True # Terminate response body to proxy
You tried adding Content-Length, but did you try “Content-Length: 0”:
def do_GET(self):
self.send_response(HTTPStatus.OK)
self.send_header("Content-Length", "0") # Stop proxy reading body
self.end_headers()
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25095>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25095] test_httpservers hangs since Python 3.5
Martin Panter <vadmium...@gmail.com> added the comment:
In the server, the send_header("Connection", "close") call sets the
“close_connection” flag. This shuts down the connection once “do_GET” returns.
Without the flag set, the server will wait and read another request.
If you want the server to shut the connection down, I suggest to be explicit in
setting “close_connection”. It should work even if no “Connection: close”
appears in the HTTP protocol. The special behaviour of “send_header” I think
you are relying on is not documented.
On my Linux computer with the original code, I think the client shuts the
connection down. This causes the server to see an empty “raw_requestline” and
return from “handle_one_request”. It returns to “serve_forever” where it polls
the “__shutdown_request” flag and sees that it should stop.
The client shuts down the connection only because of subtleties in how the HTTP
client manages the socket and how sockets are garbage collected. The response
does not have Content-Length nor Transfer-Encoding fields, and would be
terminated by the server shutting the connection down. So the HTTPConnection
object cannot reuse the TCP connection and hands ownership to the HTTPResponse
object returned by “getresponse”. Since this object is not saved anywhere, it
gets garbage collected, which closes the socket and shuts the connection down.
But perhaps on Windows the shutdown doesn’t happen, or perhaps the garbage
collector is too slow.
If I am right, closing the HTTPResponse object would also fix the deadlock. It
is good practice to close the underlying socket anyway:
with support.captured_stderr() as err:
self.con.request('GET', '/')
res = self.con.getresponse()
# Shut down connection to stop the server reading from it
res.close()
self.con.close()
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue25095>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32491] base64.decode: linebreaks are not ignored
Martin Panter <vadmium...@gmail.com> added the comment: I wrote an incremental base-64 decoder for the "codecs" module in Issue 27799, which you could use. It just does some preprocessing using a regular expression to pick four-character chunks before passing the data to a2b_base64. Or maybe implementing it properly in the "binascii" module is better. Quickly reading RFC 2045, I saw it says "All line breaks or other characters not found in Table 1 [64 alphabet characters plus padding character] must be ignored by decoding software." So this is a real bug, although I think a base-64 encoder that triggers it would be rare. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32413] Document that locals() may return globals()
Martin Panter <vadmium...@gmail.com> added the comment: FWIW a few years ago I wrote a patch for Issue 17546 that documents three personalities of “locals”, including: * At the module level, the dictionary returned is the global symbol table, also returned by :func:`globals`. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32456] PYTHONIOENCODING=undefined doesn't work in Python 3
Martin Panter <vadmium...@gmail.com> added the comment:
My guess is there is no message because in Python 3, errors are encoded
according to PYTHONIOENCODING. Perhaps it works as you expect if you bypass
sys.excepthook:
$ PYTHONIOENCODING=undefined python -c 'import sys, os; sys.excepthook = lambda
*exc: os.write(2, ascii(exc).encode()); print(u"abc")'
(, UnicodeError('undefined encoding',), )
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32456>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32434] pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if at least one component exists
New submission from Martin Liska <jugg...@gmail.com>:
The documentation for pathlib.Path.resolve says: "Make the path absolute,
resolving any symlinks."
On Windows, the behavior doesn't always match the first part of the statement.
Example:
On a system with an existing, but empty directory C:\Test.
Running the interpreter at C:\ resolve behaves like so:
>>> os.path.realpath(r'Test\file')
'C:\\Test\\file'
>>> WindowsPath(r'Test\file').resolve(strict=False)
WindowsPath('C:/Test/file')
When running the interpreter inside C:\Test it instead behaves in the following
manner:
>>> os.path.realpath('file')
'C:\\Test\\file'
>>> WindowsPath('file').resolve(strict=False)
WindowsPath('file')
Resolving a path object specifying a non-existent relative path results in an
identical (relative) path object.
This is also inconsistent with the behavior of os.path.realpath as demonstrated.
The root of the issue is in the pathlib._WindowsFlavour.resolve method at lines
193, 199 and 201.
If at least one component of the path gets resolved at line 193 by the
expression self._ext_to_normal(_getfinalpathname(s)), the path returned at line
201 will be joined from the absolute, resolved part and the unresolved remained.
If none of the components get resolved then the path will be returned at line
199 as passed into the function.
--
components: Library (Lib)
messages: 309102
nosy: mliska
priority: normal
severity: normal
status: open
title: pathlib.WindowsPath.reslove(strict=False) returns absoulte path only if
at least one component exists
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32434>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32352] `inspect.getfullargspec` doesn't work fine for some builtin callable objects
Martin Panter <vadmium...@gmail.com> added the comment: This was documented for the “getfullargspec” function in Issue 7422 (long before “signature” existed). The error message was also clarified in Issue 6905. However IMO the term “Python function” is too subtle and ambiguous. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Martin Panter <vadmium...@gmail.com> added the comment: Not if the time is associated with a particular day. Imagine implementing datetime.fromisoformat by separately calling date.fromisoformat and time.fromisoformat. The date will be off by one day if you naively rounded 2017-12-18 23:59 “up” to 2017-12-18 00:00. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Martin Panter <vadmium...@gmail.com> added the comment:
Regarding Matthieu’s RFC 3339 parser, Victor wanted to use the
round-half-to-even rule to get a whole number of microseconds. But considering
the “time” class cannot represent 24:00, how do you round up in the extreme
case past 23:59?
time.fromisoformat("23:59:59.995")
Perhaps it is better to always truncate to zero, only support 6 digits
(rejecting fractions of a microsecond), or add Anders’s
truncate_microseconds=True option.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit
Martin <mdelij...@gmail.com> added the comment: I used Python on other machines, I know how it's supposed to work. I'm using Windows 7 and this problem happened with 2.7.14, 2.7.13 and 2.7.9. I didn't bother trying all other versions because it looked like it didn't matter what version it was. For every version, I was running scripts with PyShell file (59 KB) from idlelib. I found another two files called "idle" in idlelib, one with and other without console. Either of those when ran starts Shell window and I can run scripts perfectly fine from there. I don't know what the problem is with PyShell file, but since with idle files it works as expected, I won't chase the cause of this. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32315] can't run any scripts with 2.7.x, 32 and 64-bit
New submission from Martin <mdelij...@gmail.com>: When I try to run a really simple script like: def fun(a): print a return I get this error: Exception in Tkinter callback Traceback (most recent call last): File "C:\Python27\lib\lib-tk\Tkinter.py", line 1541, in __call__ return self.func(*args) File "C:\Python27\lib\idlelib\MultiCall.py", line 166, in handler r = l[i](event) File "C:\Python27\lib\idlelib\ScriptBinding.py", line 149, in run_module_event if PyShell.use_subprocess: AttributeError: 'module' object has no attribute 'use_subprocess' It basically means Python is only usable by copy-pasting code into Shell, any kind of script fails with that error. -- components: Library (Lib) messages: 308260 nosy: DoctorEvil priority: normal severity: normal status: open title: can't run any scripts with 2.7.x, 32 and 64-bit versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32315> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17972] inspect module docs omits many functions
Change by Martin Panter <vadmium...@gmail.com>: -- dependencies: +Online doc does not include inspect.classify_class_attrs ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue17972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32247] shutil-copytree: Create dst folder only if it doesn't exist
Change by Martin Panter <vadmium...@gmail.com>: -- superseder: -> add exist_ok to shutil.copytree ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28185] Tabs in C source code
Martin Panter <vadmium...@gmail.com> added the comment: Similar changes were made in Issue 32150 and PR 3892 (tabs) and Mercurial revision 98d1788c905c (trailing space and indentation). All the other tabs in these patches appear to have been removed with other work: #29524, #31891, #30747, #31373, PR 4275, #25658, #27867, #30406, #31370, #30070, #29585, #31338, PR 1723, #30279. -- resolution: -> out of date stage: -> resolved status: open -> closed superseder: -> Expand tabs to spaces in C files ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28185> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Martin Panter <vadmium...@gmail.com> added the comment: The other difference is Mattieu guarantees ValueError for invalid input strings, which I think is good. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime: add ability to parse RFC 3339 dates and times
Martin Panter <vadmium...@gmail.com> added the comment: P-ganssle seems to be proposing to limit parsing to exactly what “datetime.isoformat” produces; i.e. whole number of seconds, milliseconds or microseconds. Personally I would prefer it without this limitation, like in Mathieu’s patches. But P-ganssle has done some documentation, so perhaps we can combine the work of each? -- nosy: +p-ganssle ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29710] Incorrect representation caveat on bitwise operation docs
Martin Panter <vadmium...@gmail.com> added the comment: FWIW I find Mark’s suggestion pretty good: “Each bitwise operation has the same result as though carried out in two's complement using a bit-width that's large enough to represent the inputs.” -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25054] Capturing start of line '^'
Martin Panter <vadmium...@gmail.com> added the comment: The new “finditer” behaviour seems to contradict the documentation about excluding empty matches if they touch the start of another match. >>> list(re.finditer(r"\b|:+", "a::bc")) [, , , , ] An empty match at (1, 1) is included, despite it touching the beginning of the match at (1, 3). My best guess is that when an empty match is found, searching continues at the same position for the first non-empty match. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25054> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)
Martin Panter <vadmium...@gmail.com> added the comment: Michael Felt: if you still want the code compatible with Python 2 and 3 (and others are happy with that), I suggest documenting that in a code comment. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue26439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32085] [Security] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!
Martin Panter <vadmium...@gmail.com> added the comment: Issue 32185 proposes to stop sending IP addresses in the TLS SNI protocol. Maybe this will help; it depends if it will catch IP address strings with with whitespace or if there are other ways to inject invalid hostnames. -- dependencies: +SSLContext.wrap_socket sends SNI Extension when server_hostname is IP ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16487] Allow ssl certificates to be specified from memory rather than files.
Martin Richard <mart...@martiusweb.net> added the comment: FWIW, PyOpenSSL allows to load certificates and keys from a memory buffer and much more. It's also fairly easy to switch from ssl to PyOpenSSL. It's probably a viable alternative in many cases. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue16487> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Martin Panter <vadmium...@gmail.com> added the comment: The doc string for the result object, and the main Python 2 documentation, both say that the result is a 10-tuple. So perhaps any new field should only be an attribute, and the tuple should stay the same size, to maintain compatibility. This was done in other cases, e.g. struct_time and stat_result. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Martin Panter <vadmium...@gmail.com> added the comment: I read in PEP 11 that Mac OS 9 support was dropped in Python 2.4. I agree that eliminating “.” and “..” components makes sense, since that is how they should be handled when resolving relative URLs. But it seems low priority, since this doesn’t happen on current supported platforms, and would only be triggered by an invalid HTTP request. -- priority: normal -> low stage: resolved -> needs patch ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue10231> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32084] [Security] http.server can be abused to redirect to (almost) arbitrary URL
Martin Panter <vadmium...@gmail.com> added the comment:
Maybe a good fix would be to “escape” the double slash with “/.”:
if os.path.isdir(path):
url = self.path
if url.startswith('//'): # E.g. "//www.python.org/%2f.."
url = "/." + url # Becomes "/.//www.python.org/%2f.."
parts = urllib.parse.urlsplit(url)
...
When this “escaped” URL is resolved with the base URL, it should give the right
result:
>>> base = "http://localhost:8000//www.python.org/%2f..;
>>> redirect = "/.//www.python.org/%2f../"
>>> urljoin(base, redirect)
'http://localhost:8000//www.python.org/%2f../'
A simpler idea is to strip off all but one of the leading slashes, so you end
up with "/www.python.org/%2f..". That would technically be a different URL, but
would access the same file through the default SimpleHTTPRequestHandler
behaviour, so most people wouldn’t notice.
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32084>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10231] SimpleHTTPRequestHandler directory bugs
Martin Panter <vadmium...@gmail.com> added the comment:
The first two bugs ("foo/dir?baz" and "foo/dir?baz/") were solved by Issue
23112. The third (".../foo.html/") was solved by Issue 17324.
That leaves the fourth complaint, which I don’t understand: ‘translate_path()
does not handle initial "."/".." on non-Posix systems’.
As far as I know, in 2010 (and still in 2017) the only non-Posix system Python
supported was Windows. But Windows has os.curdir = "." and os.pardir = "..",
just like Posix.
There is a quirk where requests like “GET .” and “GET ../path” will retain the
dots after passing through “posixpath.normpath”. If there was a platform where
a single or double dot was a legal file or directory name, the server will
access the corresponding file or directory in these cases. But this does not
seem like a problem.
I propose to close this, unless there really is a bug with non-Posix systems.
--
nosy: +martin.panter
resolution: -> out of date
stage: -> resolved
status: open -> pending
superseder: -> SimpleHTTPServer/http.server adds trailing slash after query
string
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue10231>
___
___
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 <vadmium...@gmail.com> added the comment:
Actually, the CRLF + space can be injected via percent encoding, so just
dealing with literal CRLFs and spaces wouldn’t be enough. You would have to
validate the hostname after it is decoded.
urlopen("http://127.0.0.1%0D%0A%20SLAVEOF . . . :6379/")
>>> pprint(conn.recv(300).splitlines(keepends=True))
[b'GET / HTTP/1.1\r\n',
b'Accept-Encoding: identity\r\n',
b'Host: 127.0.0.1\r\n',
b' SLAVEOF . . . :6379\r\n',
b'Connection: close\r\n',
b'User-Agent: Python-urllib/2.7\r\n',
b'\r\n']
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue30458>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32085] [Security] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages!
Martin Panter <vadmium...@gmail.com> added the comment: The square □ in the strings represents a space. Issue 1 (CRLF in HTTP request path): it looks like the %0D%0A would have to be decoded by an earlier step in the chain to "http://127.0.0.1:25/\r\nHELO . . .". This becomes like the header injection I mentioned in Issue 30458. Issue 2 (CRLF in HTTPS host): it seems this doesn’t work in Python as a side effect of Issue 22928 blocking generation of the Host field. But if you add a space you bypass that: "https://host%0D%0A%20SLAVEOF . . .:6379". -- dependencies: +CRLF Injection in httplib nosy: +martin.panter, orange ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30458] CRLF Injection in httplib
Change by Martin Panter <vadmium...@gmail.com>: -- type: -> security ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32135] Dict creation with update will result to NoneType
New submission from Martin <martin.bend...@gmail.com>:
>>> x = {"x":123}.update({"abc":123})
>>> type(x)
--
messages: 306977
nosy: thedemz
priority: normal
severity: normal
status: open
title: Dict creation with update will result to NoneType
type: behavior
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32135>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28778] wsgiref HTTP Response Header Injection: CRLF Injection
Martin Panter <vadmium...@gmail.com> added the comment: Issue 11671 is closely related and has a patch proposing to ban control characters including CRLF (but not spaces). Also see Issue 22928 which added header field validation to the HTTP client module. -- dependencies: +Security hole in wsgiref.headers.Headers nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28778> ___ ___ 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 <vadmium...@gmail.com> added the comment:
Victor opened Issue 32128 with the same complaint. I think I found the
offending article:
>>> server = NNTP_SSL("nntp.aioe.org")
>>> [response, count, first, last, name] = server.group("comp.lang.python")
>>> last
199267
>>> pprint(server.article(199265)[1].lines)
[. . .
b'Date: Fri, 24 Nov 2017 15:44:26 -0800 (PST)',
. . .
b'Message-ID: <dcaddc9c-a7b7-4120-bd30-304f58566...@googlegroups.com>',
b'Subject: Re: Python loop and web server (bottle) in the same script
(Posting',
b' On Python-List Prohibited)',
. . .
b'Content-Transfer-Encoding: quoted-printable',
. . .
b'If processing is I/O bound and not CPU bound, then asyncio should work
fine=',
b'.']
The body uses Quoted-printable encoding, and the previous line ends with an
equals sign “=”, meaning a soft line break. So the full stop is on its own
because the encoder didn’t want to fit it on the previous line. This is valid
(albeit quirky) encoding, and not a problem with the NNTP library.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue19613>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x
Martin Panter <vadmium...@gmail.com> added the comment:
If it helps, here is a basic test case I wrote for “pty.spawn”. I hope that it
exposes the problem on Free BSD, but I have only tested it on Linux.
parent = r'''\
import pty, sys
pty.spawn((sys.executable, "-c", sys.argv[1]))
'''
child = r'''\
import sys
# Read input first of all to minimize output buffering
input = sys.stdin.readline()
print("isatty: {}, {}, {}".format(
sys.stdin.isatty(), sys.stdout.isatty(), sys.stderr.isatty()))
print("input: " + repr(input))
sys.stdout.write("stdout data\n")
sys.stderr.write("stderr data\n")
'''
args = (sys.executable, "-c", parent, child)
parent = subprocess.Popen(args,
stdin=subprocess.PIPE, stdout=subprocess.PIPE)
try:
parent.stdin.write(b"stdin data\n")
parent.stdin.flush()
# Leave input open. When the child closes the slave terminal on
# Free BSD, “spawn” used to keep waiting for input (BPO 26228).
output = parent.stdout.read()
finally:
parent.stdout.close()
parent.stdin.close()
parent.wait()
self.assertEqual(0, parent.returncode, repr(output))
self.assertIn(b"isatty: True, True, True", output)
self.assertIn(br"input: 'stdin data\n'", output)
self.assertIn(b"stdout data", output)
self.assertIn(b"stderr data", output)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue26228>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32028] Syntactically wrong suggestions by the new custom print statement error message
New submission from Martin Drawitsch <martin.drawit...@gmail.com>:
I think I found a bug in the new print syntax suggestion introduced by
https://bugs.python.org/issue30597.
When the following code is executed by Python 3.6.3 inside of a .py file:
def f():
print '%d' % 2
, then Python gives the following error message:
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int
'%d' % 2)?
The "int" next to the left brace of the suggested print function is obviously
wrong.
The expected message would be:
SyntaxError: Missing parentheses in call to 'print'. Did you mean
print('%d' % 2)?
Using other values or "%s" in the formatted string in a print statement
produces the same wrong message.
This bug only seems to happen when the print statement is inside of a function
AND when it is is run inside of a .py file. At least I could not reproduce it
in the python3 REPL or outside of a function.
I am attaching the minimal example file in this bug report. Running it with "$
python3 print.py" should show the mentioned bug.
--
components: Interpreter Core
files: print.py
messages: 306231
nosy: CuriousLearner, mdraw, ncoghlan
priority: normal
severity: normal
status: open
title: Syntactically wrong suggestions by the new custom print statement error
message
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47265/print.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32028>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32009] seg fault when using Cntrl-q keymap to exit app
Martin Panter <vadmium...@gmail.com> added the comment: This looks the same as Issue 25259. The trigger is that multiple lines are generated at the same time, but Python only expects the first line. -- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> readline macros can segfault Python ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31526] Allow setting timestamp in gzip-compressed tarfiles
Martin Panter <vadmium...@gmail.com> added the comment: Perhaps you can compress the tar file using the “gzip.GzipFile” class. It accepts a custom “mtime” parameter (see Issue 4272, added in 2.7 and 3.1+): >>> gztar = BytesIO() >>> tar = GzipFile(fileobj=gztar, mode="w", mtime=0) >>> tarfile.open(fileobj=tar, mode="w|").close() >>> tar.close() >>> gztar.getvalue().hex() '1f8b080002ffedc1010d00c2a0f74f6d0e37a0008037039ade1d270028' However, “tarfile.open” accepts a “compresslevel” argument for two of the compressors, so you could argue it is okay to add another argument to pass to the gzip compressor. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31959] Directory at `TemporaryDirectory().name` does not exist
Change by Martin Panter <vadmium...@gmail.com>: -- nosy: +serhiy.storchaka resolution: wont fix -> not a bug stage: -> resolved ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31959] Directory at `TemporaryDirectory().name` does not exist
Martin Panter <vadmium...@gmail.com> added the comment: The documentation says “On . . . destruction of the temporary directory object the newly created temporary directory and all its contents are removed”. If you had enabled warnings, you may have seen a hint: $ python -Wdefault -c 'import tempfile; print(tempfile.TemporaryDirectory().name)' /usr/lib/python3.5/tempfile.py:788: ResourceWarning: Implicitly cleaning up _warnings.warn(warn_message, ResourceWarning) /tmp/tmpj6100h57 This is similar in spirit to earlier bug reports where workarounds were added, but to avoid this instance of the problem the string object returned by the “name” attribute would have to hold a reference back to the directory object. * Issue 23700: iter(NamedTemporaryFile()) * Issue 18879: NamedTemporaryFile().write(...) -- nosy: +martin.panter -serhiy.storchaka resolution: not a bug -> wont fix stage: resolved -> ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25942] subprocess.call SIGKILLs too liberally
Martin Panter <vadmium...@gmail.com> added the comment: https://github.com/python/cpython/pull/4283 adds a secondary timeout, which defaults to 1 s when there is no main timeout. But this seems complicated and arbitrary. As I understand, the main use case discussed here was waiting without a timeout for a child that exits soon after the interrupt. But are there any practical use cases or demand for: * Limiting the wait time after the interrupt (despite no timeout before the interrupt)? * Customizing this additional timeout? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue25942> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29710] Incorrect representation caveat on bitwise operation docs
Martin Panter <vadmium...@gmail.com> added the comment: I find the model in terms of “bit_length” hard to understand. You have to understand what bit_length returns, and why you added 1. Bit_length is awkward for negative numbers. It only uses the absolute value, which would give off-by-one problems with negative values, so I guess you added 1 to compensate. I understand the bitwise operations as using two’s complement extended to an unlimited width, so that negative values have a series of ones for the most-significant bits. I presume this is what your “2-adic representation” is. Having this spelled out may have helped when I was learning Python. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29710> ___ ___ 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 <vadmium...@gmail.com> added the comment: Issue 31945 proposes adding a “blocksize” parameter to HTTPConnection objects, so I suggest to closing in favour of that one. -- resolution: -> rejected superseder: -> Configurable blocksize in HTTP(S)Connection ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31935] subprocess.run() timeout not working with grandchildren and stdout=PIPE
Martin Panter <vadmium...@gmail.com> added the comment: This proposal sounds like a race condition. Closing the output pipe as a child exits means you risk missing recent output. On the other hand, if you don’t care about the output any more, close the pipe first and then wait for the child. Related discussions: Issue 30154: Similar problem, but the grandchild does not write any output Issue 26534: kill_group=True option for timeout Issue 31447: Windows-specific (?) -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31935] subprocess.run() timeout not working with grandchildren and stdout=PIPE
New submission from Martin Ritter <mce.rit...@gmail.com>: Hi, I tried to use subprocess.run(..., stdout=subprocess.PIPE, timeout=N) to run some test scripts with a given timeout. This works as expected with simple scripts. However if the script itself creates other children which write to stdout then `subprocess.run()` seems to wait for all of the children to finish. I've attached a minimal example. I looked into subprocess.py and `subprocess.run()` calls `process.communicate()` again without timeout when handling the TimeoutExpired exception which then in turn waits for the pipes to be closed by all children. If communicate() would check if the process is still alive while waiting for output and close the pipes once the process has finished the timeout feature should work as expected and descendants would get a SIGPIPE when writing to stdout/stderr. -- components: Library (Lib) files: test_killsub.py messages: 305487 nosy: Martin Ritter priority: normal severity: normal status: open title: subprocess.run() timeout not working with grandchildren and stdout=PIPE type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47251/test_killsub.py ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31894] test_timestamp_naive failed on NetBSD
Martin Panter <vadmium...@gmail.com> added the comment: Are you sure it is a “system” bug? As far as I understand, at least Posix does not require support for local time before 1970. See <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16>. But why is localtime(14400) relevant? The documentation only says “datetime.timestamp” calls “mktime”, which should be valid since the UTC-5 timezone offset will give a positive timestamp. Perhaps is this similar to Issue 29097, probing a date before 1970? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31894> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31749] Request: Human readable byte amounts in the standard library
Martin Panter <vadmium...@gmail.com> added the comment:
Ken Kundert started a related discussion a while back on Python-ideas:
<https://www.mail-archive.com/search?l=mid=20160830203427.ge2...@kundert.designers-guide.com>.
This was about SI-prefixed units in general; not restricted to bytes. Also,
the “timeit” module already does auto-scaling across nsec, usec, msec, and sec.
I think supporting decimal SI prefixes (for µs, mL, km, MW, etc) is more
important than the binary versions (KiB, MiB, GiB). And units of 1,024,000 are
definitely too niche.
I think a new format type “:h” may be the way forward. Perhaps it would add an
SI prefix, and then the user could append their unit:
>>> f"{123901842:h}B" # Six significant digits by default (like “:g”)
"123.902 MB"
>>> f"{123901842:.5h}B" # Drop trailing zeros
"123.9 MB"
>>> f"{12:+6h}m" # Sign and width options may be useful
" +12 m"
>>> f"{12e99:h}m" # Exponential notation for extreme values
"1.2e100 m"
>>> f"{12e99:H}m" # Capitalize E, INF, etc (but not k for kilo-, etc)
"1.2E100 m"
>>> f"{123901:#.5h}m" # Alternative form keeps trailing zeros
"123.90 km"
>>> f"{123:.2h}m" # Precision < 3 may not be respected
"123 m"
>>> f"{123:#.2h}m" # Maybe alternative form could respect the precision
"0.12 km"
>>> f"{123901842:.4h}B".replace(" ", "") # Avoid the space
"123.9MB"
>>> f"{123901842:.4h}B".replace(" ", "") # Alternative space
"123.9MB"
>>> f"{123901842:.4h}B".replace(".", ",") # Alternative to decimal point
"123,9 MB"
>>> f"{12e-6:h}sec" # Non-ASCII by default
"12 µsec"
>>> f"{12e-6:h}sec".replace("\N{MICRO SIGN}", "u") # ASCII compatibility
"12 usec"
Squares and cubes may be a minor stumbling block: 0.001 m² is one thousand
square millimetres, but f"{0.001:.3h}m²" would return "1 mm²".
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31749>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22671] Typo in class io.BufferedIOBase docs
Martin Panter <vadmium...@gmail.com> added the comment: I’m unlikely to soon, but I don’t mind if someone else uses my patch. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24291] Many servers (wsgiref, http.server, etc) can truncate large output blobs
Martin Panter <vadmium...@gmail.com> added the comment: Closing because I understand it is too late to do anything for 3.5 now. -- resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue24291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18670] Using read_mime_types function from mimetypes module gives resource warning
Martin Panter <vadmium...@gmail.com> added the comment: The patches would mask an OSError raised by the “readfp” call, which would be a change in behaviour. But moving the call does not seem to be necessary; why not leave it outside the “try” statement? -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue18670> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31800] datetime.strptime: Support for parsing offsets with a colon
Martin Panter <vadmium...@gmail.com> added the comment: FWIW it looks like “strptime” in glibc, and Open and Free BSD support parsing this and even more formats (RFC 822 and RFC 3339; includes “Z”, U.S. time zones, ±HH). Also, there is Issue 24954 for adding “%:z” like Gnu “date”. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31800] datetime.strptime: Support for parsing offsets with a colon
Martin Panter <vadmium...@gmail.com> added the comment: Sorry, I meant Net BSD not Free BSD -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31760] Re-definition of _POSIX_C_SOURCE with Fedora 26.
Martin Panter <vadmium...@gmail.com> added the comment: Looks the same as Issue 31374 -- nosy: +martin.panter resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> expat: warning: "_POSIX_C_SOURCE" redefined ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31712] subprocess with stderr=subprocess.STDOUT hang
Martin Panter <vadmium...@gmail.com> added the comment: Scanning over the Open SSH commits for 7.3p1 https://github.com/openssh/openssh-portable/compare/V_7_2_P2...V_7_3_P1 it looks like this commit https://github.com/openssh/openssh-portable/commit/d2d6bf864e52af8491a60dd507f85b74361f5da3 may fix your problem. It points to https://bugzilla.mindrot.org/show_bug.cgi?id=1988 -- resolution: -> third party stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31712] subprocess with stderr=subprocess.STDOUT hang
Martin Panter <vadmium...@gmail.com> added the comment: Presumuing your file descriptor 3 is the read end of the pipe to the child’s output, then there is probably a process somewhere that could still write to the write end. Normally “check_output” waits until it has read all possible output from the pipe(s). This is probably not a bug in Python. Maybe it is a bug with SSH or your “MUX” (you didn’t explain what that is) leaving a process running in the background that could output to stderr. Try to track down what processes have your pipe open. Find out the number that identifies the pipe. It is the node number in the “lsof” command, or in the symbolic link under /proc: $ lsof -a -c python -d 3 COMMAND PIDUSER FD TYPE DEVICE SIZE/OFFNODE NAME python3 26025 vadmium3r FIFO0,8 0t0 4913217 pipe $ ls -l "/proc/$(pgrep python)/fd/3" lr-x-- 1 vadmium vadmium 64 Oct 6 22:17 /proc/26025/fd/3 -> pipe:[4913217] Then look through the other files to find if other process(es) have the write end of the pipe open; “cat” in my example: $ lsof | grep 4913217 python3 26025 vadmium3r FIFO0,8 0t04913217 pipe cat 26026 vadmium1w FIFO0,8 0t04913217 pipe $ ls -l /proc/*/fd/* | grep 4913217 lr-x-- 1 vadmium vadmium 64 Oct 6 22:17 /proc/26025/fd/3 -> pipe:[4913217] l-wx-- 1 vadmium vadmium 64 Oct 6 22:16 /proc/26026/fd/1 -> pipe:[4913217] The general problem does seem to be a recurring thing with the subprocess module, so maybe more documentation or other enhancements could help. Similar reports: * Issue 31447: communicate not respecting timeout due to grandchild process * Issue 30154: subprocess.run with timeout and output pipe from grandchild * Issue 26534: check_output with shell=True and timeout doesn’t kill shell’s child * Issue 23213: communicate hang with stderr leaked in “systemd” daemon * Issue 13422: communicate hangs as long as a daemon leaves pipes open * Issue 4216: communicate hang after starting “cpboot” service -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31712> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31656] Bitwise operations for bytes-type
Martin Panter <vadmium...@gmail.com> added the comment: There’s already a bug open for this: Issue 19251. Only equal-length strings should be supported. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Change by Martin Panter <vadmium...@gmail.com>: -- Removed message: https://bugs.python.org/msg303440 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Martin Panter <vadmium...@gmail.com> added the comment: . Actually take back a lot of what I wrote above. I forgot that SimpleHTTPRequestHandler only supports HTTP 1.0; I don’t think it uses keep-alive or persistent connections, so it should close its TCP connections promptly. There may be something else going on. Unfortunately I don’t have Chrome handy to experiment with. Perhaps it is holding a TCP connection open without making any request at all, and then trying to open a second connection. You would have to look at the TCP connections being created and shut down, and the HTTP requests being made, to verify. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Martin Panter <vadmium...@gmail.com> added the comment: The change in handling KeyboardInterrupt was my intention in Issue 23430. I hope it isn’t a problem on its own :) Running the module with “python -m http.server” uses the HTTPServer class, based on socketserver.TCPServer. This only accepts one connection at a time, and waits for the SimpleHTTPRequestHandler class to finish handling each TCP connection before shutting it down and waiting for the next one. But SimpleHTTPRequestHandler supports persistent HTTP connections, meaning the TCP connection stays open after one HTTP request, ready for another. This prevents the simple TCPServer from accepting new connections. What is probably happening is the browser is trying to make one request (e.g. for domain3.html) on a new connection while it has an existing persistent connection already open. Having multiple host names pointing to the same server is not going to help; perhaps the browser does not realize that the two connections are to the same TCP server or that it could reuse the old connection. A simple workaround would be to use the socketserver.ThreadingMixIn or ForkingMixIn class. Each TCP connection will then be handled in a background thread. The mixed-in TCPServer will not wait for the handler, and will accept concurrent connections. If you want to avoid multiple threads, I think it is also possible to augment the server and handler classes to use “select” or similar so that the server will still handle each HTTP request one at a time, but can wait for requests on multiple TCP connections. But it requires subclassing and overriding some methods with custom code, and probably depends on deeper knowledge of how the classes work than is specified in the documentation. For existing versions of Python, I don’t there is much that could be done other than documenting the shortcomings of how a persistent HTTP connection vs multiple connections is handled. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ 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 <vadmium...@gmail.com> added the comment: I prefer Cornelius’s current proposal (rev 4f8137b) because it fixes both sites, rather than just patching the immediate problem site. I don’t think read(1) is a big problem, just less efficient. But if you prefer to do larger reads, that should be fine too. You could even use os.fdopen(...).readline(), which would use BufferedReader. It is not documented, but BufferedReader should do large reads and return the line without waiting to fill its internal buffer. FWIW I think it would be okay to remove the “chunked output” test. It isn’t exercising the “pty” module any more than the “Writing to slave_fd” test above it. All we need to do is verify that the “master_open” function returns a PTY master and that “slave_open” returns the corresponding slave terminal file descriptor. Checking “isatty” and sending one line of data through seems sufficient. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31158> ___ ___ 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 <vadmium...@gmail.com> added the comment: Regarding the compressed data generator, it would be better if there were no restrictions on the generator yielding empty chunks. This would match how the upload “body” parameter for HTTPConnection.request can be an iterator without worrying about empty chunks. IMO a chunked encoder should skip empty chunks and add the trailer itself, rather than exposing these special requirements to higher levels. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31520] ResourceWarning: unclosed warning
Martin Panter added the comment: I’m curious how you manage to trigger the warning in the “closed” state. The Python I have handy is half a year out of date, but all my attempts to trigger the warning either produce the less confusing version, ResourceWarning: unclosed or there is no warning at all due IOBase.__del__ (see Issue 19829). If your SocketIO was wrapped in a BufferedReader/Writer/RWPair, then that could easily close the SocketIO object before SocketIO.__del__ is called. You would also have to override the wrapper’s __del__ method, rather than (or as well as) SocketIO.__del__. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31520> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31351] ensurepip discards pip's return code which leads to broken venvs
Martin Vielsmaier added the comment: I guess this is also the root cause for the problem I reported on virtualenv: https://github.com/pypa/virtualenv/issues/1074 -- nosy: +Martin Vielsmaier ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31504] Documentation for return value for string.rindex is missing when search string is empty
Martin Panter added the comment: The behaviour for searching for empty strings in Python is inconsistent; see Issue 24243. IMO the behaviour for the (r)find/index methods is sensible, but it is worth making the documentation explicit. The returned indexes you have given (5, 1, and 0) are valid for slicing. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31487] Improve f-strings documentation wrt format specifiers
Martin Panter added the comment:
>>> f"{number:#0x}" # using integer format specifier
It’s not clear what your purpose was adding the above line, but the zero flag
(0) does nothing because there is no “width” field. I think it could be
misleading, because it is actually the “#x” codes that generate the “0x” prefix.
If you want to illustrate a minimum width, I suggest something like
>>> f"{number:#06x}"
'0x0400'
or (if the number is never negative)
>>> f"0x{number:04X}"
'0x0400'
Or if you don’t care about the width:
>>> f"{number:#x}"
'0x400'
--
nosy: +martin.panter
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31487>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31495] Wrong offset with IndentationError ("expected an indented block")
Martin Panter added the comment: Some relevant info I wrote in Issue 25677: ‘The caret points to the character _before_ offset. . . . In some cases (e.g. the line “1 +”), the offset is the string index _after_ the error. But in the case of “1;1 + 1 = 2”, offset is the index where the error (statement) begins.’ In this case it looks like the offset is of the end of the first word on the line that has the wrong indentation. The caret is positioned one position back, to point at the last character of that word. -- nosy: +martin.panter ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31495> ___ ___ 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: . Isn’t your use of “cmd” similar enough to shell=True? I.e. isn’t that a “cmd” parent process spawning a “waitfor” child? If your 4 s “subprocess.run” call times out, does it kill the “waitfor” process, or leave it running? Could the “waitfor” process write to stdout or stderr, and should that be captured by your 20 s “communicate” call? -- ___ 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
[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
[issue28287] Refactor subprocess.Popen to let a subclass handle IO asynchronously
Martin Richard added the comment: Yes, the goal is to isolate the blocking IO in __init__ into other methods so Popen can be subclassed in asyncio. The end goal is to ensure that when asyncio calls Popen(), it doesn't block the process. In the context of asyncio, there's no need to make Popen() IOs non-blocking as they will be performed with the asyncio API (rather than the IO methods provided by the Popen object). -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28287> ___ ___ 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
