[issue41987] singledispatchmethod raises an error when relying on a forward declaration
Jörn Heissler added the comment: Hello! git-bisect points at https://bugs.python.org/issue41341 https://github.com/python/cpython/pull/21553 It breaks both the examples from https://bugs.python.org/issue41987#msg379896 and https://bugs.python.org/issue41987#msg380803 -- nosy: +joernheissler ___ Python tracker <https://bugs.python.org/issue41987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37773] ValueError: I/O operation on closed file. in ZipFile destructor
Jörn Heissler added the comment: Still reproducible in cpython 3.10.0a3 (debian unstable) and 3.10.0a6 (pyenv). -- versions: +Python 3.10 ___ Python tracker <https://bugs.python.org/issue37773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37773] ValueError: I/O operation on closed file. in ZipFile destructor
Jörn Heissler added the comment: Thanks Serhiy for the explanation, it's making sense now. Guess whatever I did back then (no idea what I was working on) was basically a mistake; I should have closed my ZipFile properly, e.g. by using context managers. So maybe it's not really a cpython bug. I ran a git-bisect back then and came up with https://hg.python.org/lookup/ada319bb6d0ebcc68d3e0ef2b4279ea061877ac8 as cause. -- ___ Python tracker <https://bugs.python.org/issue37773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39124] round Decimal error
Jörn Heissler added the comment: > round(9.925, 2) => 9.93 9.925 is 9.925710542735760100185871124267578125 on my platform. This is larger than 9.925, so the "round-ties-to-even" rule can't be applied. Instead it is rounded up to 9.93 (9.92971578290569595992565155029296875). -- nosy: +joernheissler ___ Python tracker <https://bugs.python.org/issue39124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31711] ssl.SSLSocket.send(b"") fails
Jörn Heissler added the comment: Manpage (openssl 1.1.1d) now states: You should not call SSL_write() with num=0, it will return an error. SSL_write_ex() can be called with num=0, but will not send application data to the peer. SSL_write_ex was added in 1.1.1 So it looks like openssl cleaned up another mistake by defining SSL_write_ex's behaviour to be a noop. -- ___ Python tracker <https://bugs.python.org/issue31711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39318] NamedTemporaryFile could cause double-close on an fd if _TemporaryFileWrapper throws
Change by Jörn Heissler : -- nosy: +joernheissler ___ Python tracker <https://bugs.python.org/issue39318> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Jörn Heissler added the comment: Hello, https://www.python.org/dev/peps/pep-0572/#change-to-evaluation-order mentions a change of evaluation order for dict comprehensions. It looks like this is not implemented yet (as of commit 66d47da8). Will this be implemented in this issue, or should I create a new one? Thanks -- nosy: +joernheissler ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Change by Jörn Heissler : -- pull_requests: +13980 pull_request: https://github.com/python/cpython/pull/14139 ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Jörn Heissler added the comment: I tried and it appears to work: https://github.com/python/cpython/pull/14139 As I'm not familiar with cpython code, chances are that I missed something important. -- ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Jörn Heissler added the comment: Pablo, https://bugs.python.org/issue37359 was created yesterday, i.e. before the merge. -- ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Jörn Heissler added the comment: Sorry, I guess that's something completely different. So maybe the issue is related to my pull request. -- ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35224] PEP 572: Assignment Expressions
Jörn Heissler added the comment: My working theory: The change modifies the MAP_ADD instruction and also what the instruction expects to find on the stack. When *.pyc files are kept, the code generates the old stack layout (TOS=key, TOS1=value), but cpython will assume it's the other way round. I.e. all *.pyc files created before the change won't work with later cpython versions, and vice versa. I assume the build bots don't remove *.pyc files. How large an issue is that? -- ___ Python tracker <https://bugs.python.org/issue35224> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37642] timezone allows no offset from range (23:59, 24:00)
New submission from Jörn Heissler :
https://bugs.python.org/issue5288 changed datetime.timezone to accept
sub-minute offsets.
The C implementation allows offsets from range (23:59, 24:00) while the python
implementation does not:
# C
>>> timezone(timedelta(seconds=86399))
datetime.timezone(datetime.timedelta(seconds=86399))
# Python
>>> timezone(timedelta(seconds=86399))
Traceback (most recent call last):
File "", line 1, in
File "cpython/Lib/datetime.py", line 2194, in __new__
raise ValueError("offset must be a timedelta "
ValueError: offset must be a timedelta strictly between -timedelta(hours=24)
and timedelta(hours=24).
This is because _maxoffset is defined as timedelta(hours=23, minutes=59)
Second issue: The (undocumented) "min" and "max" attributes (both C and python)
show 23:59
even though the C implementation can get closer to 24:00.
Should this be changed to timezone(timedelta(seconds=86399,
microseconds=99))?
(Same applies to the minimums)
--
components: Library (Lib)
messages: 348237
nosy: joernheissler
priority: normal
severity: normal
status: open
title: timezone allows no offset from range (23:59, 24:00)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37642>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37772] zipfile.Path.iterdir() outputs sub directories many times or not at all
New submission from Jörn Heissler :
Hello,
#!/usr/bin/python3.8
from zipfile import ZipFile, Path
import io
def recurse_print(parent):
for child in parent.iterdir():
if child.is_file():
print(child, child.read_text())
if child.is_dir():
recurse_print(child)
data = io.BytesIO()
zf = ZipFile(data, "w")
zf.writestr("a.txt", "content of a")
zf.writestr("b/c.txt", "content of c")
zf.writestr("b/d/e.txt", "content of e")
zf.writestr("b/f.txt", "content of f")
zf.filename = "abcde.zip"
root = Path(zf)
recurse_print(root)
Expected result:
abcde.zip/a.txt content of a
abcde.zip/b/c.txt content of c
abcde.zip/b/f.txt content of f
abcde.zip/b/d/e.txt content of e
Actual result:
abcde.zip/a.txt content of a
abcde.zip/b/c.txt content of c
abcde.zip/b/f.txt content of f
abcde.zip/b/d/e.txt content of e
abcde.zip/b/c.txt content of c
abcde.zip/b/f.txt content of f
abcde.zip/b/d/e.txt content of e
Path._add_implied_dirs adds the sub directory "b/" twice: once for each direct
child (i.e. "c.txt" and "f.txt")
And similarly:
data = io.BytesIO()
zf = ZipFile(data, "w")
zf.writestr("a.txt", "content of a")
zf.writestr("b/d/e.txt", "content of e")
zf.filename = "abcde.zip"
root = Path(zf)
recurse_print(root)
Expected result:
abcde.zip/a.txt content of a
abcde.zip/b/d/e.txt content of e
Actual result:
abcde.zip/a.txt content of a
Here, Path._add_implied_dirs doesn't add "b/" at all, because there are no
direct childs of "b".
--
components: Library (Lib)
messages: 349101
nosy: joernheissler
priority: normal
severity: normal
status: open
title: zipfile.Path.iterdir() outputs sub directories many times or not at all
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue37772>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37773] ValueError: I/O operation on closed file. in ZipFile destructor
New submission from Jörn Heissler : When running this code: from zipfile import ZipFile import io def foo(): pass data = io.BytesIO() zf = ZipFile(data, "w") I get this message: Exception ignored in: Traceback (most recent call last): File "/home/user/git/oss/cpython/Lib/zipfile.py", line 1800, in __del__ File "/home/user/git/oss/cpython/Lib/zipfile.py", line 1817, in close ValueError: I/O operation on closed file. Comment out def foo: pass, and there is no error. It looks like the bug was introduced with commit ada319bb6d0ebcc68d3e0ef2b4279ea061877ac8 (bpo-32388). -- messages: 349104 nosy: joernheissler, pitrou priority: normal severity: normal status: open title: ValueError: I/O operation on closed file. in ZipFile destructor type: crash versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37773> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35784] document that hashlib.new takes kwargs
New submission from Jörn Heissler :
This code works:
hashlib.new('blake2b', b'foo', digest_size=7)
https://github.com/python/cpython/blob/master/Lib/hashlib.py#L7
documents the function as: new(name, data=b'', **kwargs)
But the **kwargs argument is missing in
https://docs.python.org/3/library/hashlib.html#hashlib.new and there aren't any
examples either.
--
assignee: docs@python
components: Documentation
messages: 334053
nosy: docs@python, joernheissler
priority: normal
severity: normal
status: open
title: document that hashlib.new takes kwargs
type: enhancement
___
Python tracker
<https://bugs.python.org/issue35784>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31711] ssl.SSLSocket.send(b"") fails
New submission from Jörn Heissler : Traceback (most recent call last): File "client.py", line 10, in conn.send(b'') File "/usr/lib/python3.6/ssl.py", line 941, in send return self._sslobj.write(data) File "/usr/lib/python3.6/ssl.py", line 642, in write return self._sslobj.write(data) ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2074) This error is not what I expected. I expected a noop instead. My guess is, that python calls SSL_write (3.6 branch, _ssl.c:2038) with that empty buffer. The manpage states: "When calling SSL_write() with num=0 bytes to be sent the behaviour is undefined." This undefined behaviour should either be documented in python, or defined to either raise an exception (ValueError?) or defined as a noop. I'd prefer the latter. -- assignee: christian.heimes components: SSL files: client.py messages: 303810 nosy: christian.heimes, joernheissler priority: normal severity: normal status: open title: ssl.SSLSocket.send(b"") fails type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file47194/client.py ___ Python tracker <https://bugs.python.org/issue31711> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34465] ipaddress should accept bytearray in addition to bytes
New submission from Jörn Heissler :
Hi,
the ipaddress module accepts `bytes' objects in the constructors.
`bytearray' however is not supported, see paste below.
Should this be supported too?
>>> import ipaddress
>>> ipaddress.IPv4Address(bytes([127, 0, 0, 1]))
IPv4Address('127.0.0.1')
>>> ipaddress.IPv4Address(bytearray([127, 0, 0, 1]))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.7/ipaddress.py", line 1301, in __init__
self._ip = self._ip_int_from_string(addr_str)
File "/usr/lib/python3.7/ipaddress.py", line 1135, in _ip_int_from_string
raise AddressValueError("Expected 4 octets in %r" % ip_str)
ipaddress.AddressValueError: Expected 4 octets in
"bytearray(b'\\x7f\\x00\\x00\\x01')"
--
components: Library (Lib)
messages: 323906
nosy: joernheissler
priority: normal
severity: normal
status: open
title: ipaddress should accept bytearray in addition to bytes
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34465>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34465] ipaddress should accept bytearray in addition to bytes
Jörn Heissler added the comment: My use case is parsing binary data. For that I use a bytearray as a buffer. buf[:4] gets me another bytearray which I'd want to convert to an ipaddress. I can't think of a usecase for list-of-int. -- ___ Python tracker <https://bugs.python.org/issue34465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34465] ipaddress should accept bytearray in addition to bytes
Jörn Heissler added the comment: That's what I'm doing now. But it would be more convenient if I could pass a bytearray. -- ___ Python tracker <https://bugs.python.org/issue34465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34465] ipaddress should accept bytearray in addition to bytes
Jörn Heissler added the comment: > Maybe add a special purposed named constructor IPv4Address.from_bytes() that > will accept any objects supporting the buffer protocol? That would work for me. I wonder if there should be something like ipaddress.ip_address_from_bytes too that can construct IPv4Adress or IPv6Address. -- ___ Python tracker <https://bugs.python.org/issue34465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
