[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing
Enrico Zini added the comment: Oh! Fair enough, I had missed it. Does the note also involve `Py_BuildValue`? If so, the documentation of `Py_BuildValue` should probably be updated; if not, I think it would be clearer if the note mentioned that it only applies to parsing, not building, values. -- ___ Python tracker <https://bugs.python.org/issue37465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37465] Incorrect documentation for `s#` arguments in C API argument parsing
New submission from Enrico Zini : In https://docs.python.org/3.9/c-api/arg.html, in the documentation for parsing argument, there is: s# (str, read-only bytes-like object) [const char *, int or Py_ssize_t] In my amd64 system, `Py_ssize_t` is a different type than `int`, and passing a `Py_ssize_t` causes undefine behaviour. I assume this has been switched to an `int` in the API, and that thisinstance of the documentation has not been updated accordingly. At the bottom of the page in the documentation of `Py_BuildValue`, `s#` is correctly documented as using an `int` and no `Py_ssize_t`, for example. -- assignee: docs@python components: Documentation messages: 346974 nosy: docs@python, enrico priority: normal severity: normal status: open title: Incorrect documentation for `s#` arguments in C API argument parsing versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
Enrico Zini added the comment: Thanks! Clarifying "number of records buffered" would perfectly solve the problem for me. -- ___ Python tracker <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36180] mboxMessage.get_payload throws TypeError on malformed content type
New submission from Enrico Zini :
This simple code:
```
import mailbox
mbox = mailbox.mbox("broken.mbox")
for msg in mbox:
msg.get_payload()
```
Fails rather unexpectedly:
```
$ python3 broken.py
Traceback (most recent call last):
File "broken.py", line 5, in
msg.get_payload()
File "/usr/lib/python3.7/email/message.py", line 267, in get_payload
payload = bpayload.decode(self.get_param('charset', 'ascii'), 'replace')
TypeError: decode() argument 1 must be str, not tuple
```
(I'm attaching a zip with code and mailbox)
I would have expected either that the part past text/plain is ignored if it
doesn't make sense, or that content-type is completely ignored.
I have to process a large mailbox archive, and this is currently how I had to
work around this issue, and it's causing me to have to skip email content which
would otherwise be reasonably accessible:
https://salsa.debian.org/nm-team/echelon/commit/617ce935a31f6256257ffb24e11a5666306406c3
--
files: broken.zip
messages: 337091
nosy: enrico
priority: normal
severity: normal
status: open
title: mboxMessage.get_payload throws TypeError on malformed content type
Added file: https://bugs.python.org/file48184/broken.zip
___
Python tracker
<https://bugs.python.org/issue36180>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32935] Documentation falsely leads to believe that MemoryHandler can be used to wrap SMTPHandler to send multiple messages per email
New submission from Enrico Zini <enr...@enricozini.org>: In the handlers documentation, MemoryHandler directly follows SMTPHandler. SMTPHandler does not document that it is sending an email per every logging invocation, but one can sort of guess it. Right afterwards, there is the documentation of MemoryHandler, which seems to hint that one can use it to buffer up log lines and send all of them with SMTPHandler at flush time, by using it as a target. What really happens when trying to do that, is that at flush time an email per buffered log line is sent instead. It would have saved me significant time and frustration if I had found in SMTPHandler a note saynig that in order to buffer up all log messages and send them as a single email, one needs to reimplement BufferingHandler and all the email composition/sending logic, and the existing handlers provide no build-in facility for doing that. -- components: Library (Lib) messages: 312710 nosy: enrico priority: normal severity: normal status: open title: Documentation falsely leads to believe that MemoryHandler can be used to wrap SMTPHandler to send multiple messages per email versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32934] logging.handlers.BufferingHandler capacity is unclearly specified
New submission from Enrico Zini <enr...@enricozini.org>: BufferingHandler's documentatio says "Initializes the handler with a buffer of the specified capacity." but it does not specify what capacity means. One would assume the intention is to give a bound to memory usage, and that capacity is bytes. Looking at the source instead, the check is: return (len(self.buffer) >= self.capacity) and self.buffer is initialised with an empty list, so capacity is a number of lines, which cannot be used to constrain memory usage, and for which I struggle to see a use case. I believe that the current behaviour is counterintuitive enough to deserve, if not changing, at least documenting -- components: Library (Lib) messages: 312709 nosy: enrico priority: normal severity: normal status: open title: logging.handlers.BufferingHandler capacity is unclearly specified versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11608] GzipFile cannot be used for streaming
New submission from Enrico Zini enr...@enricozini.org: Hello, this snippet does not work, because GzipFile wants a file-like object that can do tell() and seek(): #!/usr/bin/python import gzip from urllib import urlopen zfd = urlopen(http://ftp.debian.org/debian/dists/sid/Contents-udeb.gz;) fd = gzip.GzipFile(fileobj=zfd, mode=r) for line in fd: foobar(line) It must be possible to build a decompressing file-like object wrapper that can do without seeking, since it is obviously not a limitation of gzip decompression libraries. It would be extremely useful to have such a thing, as shown in the example snippet above. Some more details (including a very annoying misrepresentation of the issue found in Dive Into Python) can be found at http://www.enricozini.org/2011/cazzeggio/python-gzip/ (I apologise about the ranting tone of the post). -- components: Library (Lib) messages: 131427 nosy: enrico priority: normal severity: normal status: open title: GzipFile cannot be used for streaming type: behavior versions: Python 2.5, Python 2.6, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11608 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11576] timedelta subtraction glitch on big timedelta values
New submission from Enrico Zini enr...@enricozini.org: Hello, I was testing edge case behaviour of some code of mine and stumbled into this unexpected domain error from timedelta: from datetime import * timedelta(9, 86399, 99) - timedelta(9, 86399, 98) Traceback (most recent call last): File stdin, line 1, in ? OverflowError: days=-10; must have magnitude = 9 The expected result is of course timedelta(0, 0, 1): timedelta(9, 86399, 98) + timedelta(0, 0, 1) datetime.timedelta(9, 86399, 99) Both time deltas are within the range documented in /usr/share/doc/python-doc/html/lib/datetime-timedelta.html I could reproduce it on 2.6.6 and 3.1.3. I don't have access to other python versions. Ciao, Enrico Note: I reported it 4 years ago in the Debian BTS (http://bugs.debian.org/408872) but I noticed now that the Debian maintainer doesn't seem to have bothered forwarding it here :( -- messages: 131155 nosy: enrico priority: normal severity: normal status: open title: timedelta subtraction glitch on big timedelta values type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11576 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
