[issue34529] add the option for json.dumps to return newline delimited json
Michał Radwański added the comment: So this format is just a series of JSON, delimited by a newline. Instead of changing API, you might consider this piece of code: def ndjsondump(objects): return '\n'.join(json.dumps(obj) for obj in objects) Conversely, first you `str.splitlines`, then `json.loads` each line separately. Does it satisfy your needs? -- nosy: +enedil ___ Python tracker <https://bugs.python.org/issue34529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34443] enum repr should use __qualname__
Michał Radwański added the comment: Serhiy, would it be ok to put '__module__' + '.' + __qualname__ here? -- nosy: +enedil ___ Python tracker <https://bugs.python.org/issue34443> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34501] PyType_FromSpecWithBases: spec->name is dereferenced before checking for NULL
Michał Radwański added the comment: But if the error message is set, then for consistency, it should be also the case that the later checks set some kind of error message. -- nosy: +enedil ___ Python tracker <https://bugs.python.org/issue34501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34498] Python 3.7 breaks on singledispatch_function.register(pseudo_type), which Python 3.6 accepted
Michał Radwański added the comment: The change is not only in the added `isinstance` check: ~ $ python3.6 -q >>> import typing >>> isinstance(typing.Sequence, type) True >>> ~ $ python3.7 -q >>> import typing >>> isinstance(typing.Sequence, type) False >>> -- nosy: +enedil ___ Python tracker <https://bugs.python.org/issue34498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Michał Radwański added the comment: The point is that the specification is not complete and thus left for the implementations to decide. Python's version hits the sweet spot between inclusive and correct - as long as a version is unambiguous, it is accepted. -- ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34453] ipaddress module accepts some strange IPv6 addresses that it shouldn't
Michał Radwański added the comment: According to the RFC ( https://tools.ietf.org/html/rfc4291#section-2.2 ), last four bytes can be an address in the format of IPv4 address. The latter doesn't specify whether leading zeros are permitted or not. For illustration let's look at the implementation of the POSIX function `inet_aton` from Fedora 28, as documented by manual: > In all of the above forms, components of the dotted address can be > specified in decimal, octal (with a leading 0), or hexadecimal, with a > leading 0X). But notice that if you prefix a 0 with 0, the value stays the same, so it doesn't hurt not to raise errors if given either of ::::::00.00.00.00 ::::::000.000.000.000 If however you try ::::::000.000.010.000 then the address is ambiguous, so appropriately you get AddressValueError: Ambiguous (octal/decimal) value in '010' not permitted in '000.000.010.000' in '::::::000.000.010.000' I believe the issue is handled correctly. -- nosy: +enedil ___ Python tracker <https://bugs.python.org/issue34453> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34423] Overflow when casting from double to time_t, and_PyTime_t.
Michał Radwański added the comment: Although you're right - this issue is specific to pytime.c, when _Py_InIntegralTypeRange() is used with a double, it is actually true that _Py_InIntegralTypeRange() is used with double, in pytime.c only (as a quick recursive grep discovers). Perhaps the macro should be renamed not to cause confusion (include note about floating point, or define it as a function). I don't have good idea on how this issue could be resolved otherwise. -- ___ Python tracker <https://bugs.python.org/issue34423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34423] Overflow when casting from double to time_t, and_PyTime_t.
Change by Michał Radwański : -- keywords: +patch pull_requests: +8278 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32367] [Security] CVE-2017-17522: webbrowser.py in Python does not validate strings
Change by Michał Radwański : -- pull_requests: +8277 ___ Python tracker <https://bugs.python.org/issue32367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34423] Overflow when casting from double to time_t, and_PyTime_t.
New submission from Michał Radwański : Code triggering bug: import time time.sleep(2**63 / 10**9) Result: ValueError: sleep length must be non-negative The problem is with the macro that checks the range of provided double: Line 228 of Include/pymath.h: #define _Py_InIntegralTypeRange(type, v) (_Py_IntegralTypeMin(type) <= v && v <= _Py_IntegralTypeMax(type)) The type here is _PyTime_t, which is a typedef to int64_t. Proposed solution is to change <= into <, since float(2**63-1) == float(2**63), and that means that none double can ever be equal to 2**63-1. -- components: Interpreter Core messages: 323676 nosy: belopolsky, enedil, lemburg, vstinner priority: normal severity: normal status: open title: Overflow when casting from double to time_t, and_PyTime_t. type: behavior versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30656] typo in PyModule_New documentation
Changes by Michał Radwański : -- pull_requests: + ___ Python tracker <http://bugs.python.org/issue30656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30637] Syntax error reported on compile(...), but not on compile(..., ast.PyCF_ONLY_AST)
Michał Radwański added the comment: Docs mention: ast.parse(source, filename='', mode='exec') Parse the source into an AST node. Equivalent to compile(source, filename, mode, ast.PyCF_ONLY_AST). If you just parse code into AST, you first check whether it is possible to turn such source into a Python syntax tree. In that case, it obviously is, as you may imagine a function, that returns nothing: def func(): return If however you try to make executable code of the source, it is checked whether the constructs make sense in provided context. And, as you may imagine, top-level code with return statement is not valid, hence the error. -- nosy: +enedil ___ Python tracker <http://bugs.python.org/issue30637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
