[issue46770] ConfigParser(dict_type=) not behaving as expected
Cyril Jouve added the comment: you need to pass `strict=False` to ConfigParser : When `strict` is True, the parser won't allow for any section or option duplicates while reading from a single source (file, string or dictionary). Default is True. -- nosy: +Cyril Jouve ___ Python tracker <https://bugs.python.org/issue46770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45713] gcc warning when compiling Modules/expat/xmltok_ns.c
Change by Cyril Jouve : -- keywords: +patch nosy: +Cyril Jouve nosy_count: 2.0 -> 3.0 pull_requests: +29393 stage: -> patch review pull_request: https://github.com/python/cpython/pull/31022 ___ Python tracker <https://bugs.python.org/issue45713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46159] Segfault when using trace functions in 3.11a3
Cyril Jouve added the comment: this looks related to https://github.com/nedbat/coveragepy/issues/1294 / https://github.com/nedbat/coveragepy/issues/1316 related to binary incompatibility in coverage (6.2) binary wheel built with 3.11alpha2 and running on 3.11alpha3 or later. Latest release of coverage (6.3) do not ship binary wheel for python 3.11 anymore, so it's installed and built with your current python. -- nosy: +Cyril Jouve ___ Python tracker <https://bugs.python.org/issue46159> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44000] Current PY_VERSION 3.10.0a7+ does not conform to PEP 440
Cyril Jouve added the comment: sure, I'll raise the issue with poetry then. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44000] Current PY_VERSION 3.10.0a7+ does not conform to PEP 440
New submission from Cyril Jouve : It was changed from 3.10.0a7 to 3.10.0a7+ in https://github.com/python/cpython/commit/04eecf7fac8bb8d7a19d14cf2009088046956ab5 According to https://www.python.org/dev/peps/pep-0440/#public-version-identifiers, it should be something like 3.10.0a7.post1 or with https://www.python.org/dev/peps/pep-0440/#local-version-identifiers, it should be something like 3.10.0a7+post see also implementation in packaging: https://github.com/pypa/packaging/blob/main/packaging/version.py#L225 -- messages: 392607 nosy: Cyril Jouve priority: normal severity: normal status: open title: Current PY_VERSION 3.10.0a7+ does not conform to PEP 440 ___ Python tracker <https://bugs.python.org/issue44000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30988] Exception parsing invalid email address headers starting or ending with dot
Cyril Nicodème added the comment: Hi! I confirm this problem too, also with the SMTPUTF8 policy. I was able to reproduce this error on my end (Python v3.7.5). Note that when calling `message_from_bytes` without policy, there is no errors. -- nosy: +cnicodeme ___ Python tracker <https://bugs.python.org/issue30988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
Cyril Nicodème added the comment: This thread has been really interesting to follow, I'm glad to have opened it :) I would agree with Barry here, it should follow the documentation. BUT, I would suggest to add a "strict" parameter that would throw exceptions depending on the parsing issue (missing a @, having multiple @, etc). That way, a basic usage would return the empty strings, letting the developer know the email is invalid, and advanced case would still be possible. By default, I think having strict set to False would be logical, since it would follow the documentation. -- ___ Python tracker <https://bugs.python.org/issue34155> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34155] email.utils.parseaddr mistakenly parse an email
New submission from Cyril Nicodème :
Hi!
I'm trying to parse some emails, and I discovered that email.utils.parseaddr
wrongly parse an email.
Here's the corresponding header:
> From: =?utf-8?Q?z...@redacted.com.cn=E3=82=86=E2=86=91=E3=82=86?=
=?utf-8?Q?=E3=82=83=E3=82=85=E3=81=87=E3=81=BA=E3=81=BD=E3=81=BC"\=E3?=
=?utf-8?Q?=81=A9=E3=81=A5=E3=81=A2l=E3=81=A0=E3=81=B0=E3=81=A8=E3=81?=
=?utf-8?Q?=8FKL=E3=81=84=E3=82=8C=E3=82=8B=E3=82=86>KL=E3=82=89JF?=
Once this has been parsed via `decode_header`, we obtain this value:
> From: z...@redacted.com.cnゆ↑ゆゃゅぇぺぽぼ"\どづぢlだばとくKLいれるゆ>KLらJF
(I agree, not really a nice looking From email ...)
Then, when this value is given to parseaddr, here's the result:
> ('', 'z...@redacted.com.cnゆ↑ゆゃゅぇぺぽぼ')
But it should be:
> ('z...@redacted.com.cnゆ↑ゆゃゅぇぺぽぼ"\どづぢlだばとくKLいれるゆ>KLらJF', 'm...@redacted2.com')
(Note that the email in the "name" part is not the same as the email in the
"email" part!)
--
components: email
messages: 321956
nosy: Cyril Nicodème, barry, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.parseaddr mistakenly parse an email
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue34155>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33560] tuple.index() could return a more explicit error message
New submission from Cyril Roelandt <croel...@redhat.com>: The tuple.index() method returns an error message that does not allow users to know what element was being looked for inside the tuple: >>> ().index(1) Traceback (most recent call last): File "", line 1, in ValueError: tuple.index(x): x not in tuple The list.index() method has a much better error message: >>> [].index(1) Traceback (most recent call last): File "", line 1, in ValueError: 1 is not in list We could improve tuple.index() so that its behaviour becomes similar to that of list.index(). -- messages: 316955 nosy: Cyril Roelandt priority: normal severity: normal status: open title: tuple.index() could return a more explicit error message type: enhancement versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33560> ___ ___ 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()
Cyril Martin <mcool...@gmail.com> added the comment: Hello Vinay, I strongly disagree with you. In the Python documentation (https://docs.python.org/3/library/logging.html), we can read the following for the debug function: > The third keyword argument is extra which can be used to pass a dictionary > which is used to populate the __dict__ of the LogRecord created for the > logging event with user-defined attributes. It never says 'BUT IF you use the LoggerAdapter'. So the current behavior differs from what is explained in the documentation: there is an issue. By the way, I don't ask to fix the documentation, I prefer a consistent logging API. I simply cannot think a use case where we want extras of the logging statement be ignored. Regards, -- ___ 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
[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
[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
[issue24850] syslog.syslog() does not return error when unable to send the log
New submission from Cyril Bouthors:
Hi guys,
syslog.syslog() does not report any error when it fails to send messages to
syslog. To reproduce:
Stop sysglog:
sudo /etc/init.d/rsyslog stop
Run than Python code:
import syslog
syslog.syslog('test')
It does not fail.
Strace shows that's it's been unable to send the message to syslog:
connect(3, {sa_family=AF_LOCAL, sun_path=/dev/log}, 110) = -1 ENOENT (No such
file or directory)
close(3)= 0
rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7fc899e4a8d0}, {0x55e6b0, [],
SA_RESTORER, 0x7fc899e4a8d0}, 8) = 0
brk(0x20ed000) = 0x20ed000
exit_group(0) = ?
+++ exited with 0 +++
I've tested all those versions:
echo -e import syslog\nsyslog.syslog('test')\n | python3.5
echo -e import syslog\nsyslog.syslog('test')\n | python3.4
echo -e import syslog\nsyslog.syslog('test')\n | python3.3
echo -e import syslog\nsyslog.syslog('test')\n | python3.2
echo -e import syslog\nsyslog.syslog('test')\n | python2.7
echo -e import syslog\nsyslog.syslog('test')\n | python2.6
Can we please get syslog() to report errors?
Thanks.
--
components: Library (Lib)
messages: 248462
nosy: Cyril Bouthors
priority: normal
severity: normal
status: open
title: syslog.syslog() does not return error when unable to send the log
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24850
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9177] ssl.read/write on closed socket raises AttributeError
New submission from Cyril c...@excellency.fr:
This:
import socket, ssl
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
ssl_sock = ssl.wrap_socket(s)
ssl_sock.connect(('www.verisign.com', 443))
ssl_sock.close()
ssl_sock.read(1024)
raises:
Traceback (most recent call last):
File /tmp/bug.py, line 10, in module
ssl_sock.read(1024)
File /path/to/lib/python2.7/ssl.py, line 138, in read
return self._sslobj.read(len)
AttributeError: 'NoneType' object has no attribute 'read'
I would expect a socket.error instead, which mimics the way regular sockets
behave. Indeed, this code:
import socket, ssl
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('www.verisign.com', 80))
s.close()
s.recv(1024)
raises:
Traceback (most recent call last):
File /tmp/bug.py, line 6, in module
s.recv(1024)
File /path/to/lib/python2.7/socket.py, line 170, in _dummy
raise error(EBADF, 'Bad file descriptor')
socket.error: [Errno 9] Bad file descriptor
I've tested on the latest trunks on both 2.7 and 3.2. I've also tested on 2.6
and 3.1.
I can write a patch that fixes it if the bug is accepted.
--
components: Library (Lib)
messages: 109379
nosy: cbay
priority: normal
severity: normal
status: open
title: ssl.read/write on closed socket raises AttributeError
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9177
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: Here is a patch that implements SSLSocket.get_mode/set_mode, with the SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER constants defined in the ssl module. The patch contains a test case and documentation. It's made against trunk 44327 and also applies nicely with --fuzz=3 on a 2.6.5. There are no compatibility issues as no specific mode is set by default. It's up to the application to call SSLSocket.set_mode before use. I've tested my own use case with a set_mode(SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER), it works nicely. -- Added file: http://bugs.python.org/file16800/ssl_mode.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: I had a look at how M2Crypto and pyOpenSSL handled this: - M2Crypto has wrappers around SSL_set_mode that let you set the modes you want. From their changelog [1], it was required to be able to operate with Twisted. By default, though, they only set SSL_MODE_AUTO_RETRY. - pyOpenSSL enables everything by default, and there's no set_mode wrapper. Here is the relevant code: /* Some initialization that's required to operate smoothly in Python */ SSL_CTX_set_mode(self-ctx, SSL_MODE_ENABLE_PARTIAL_WRITE | SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER | SSL_MODE_AUTO_RETRY); I don't see any other possible alternative. I'm not sure which one is better. Implementing a set_mode wrapper with no mode set by default has no compatibility issues, although we'd still have that 'bad write retry' OpenSSL error. On the other hand, setting SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default is easy but we lose some security (and, possibly, some compatibility problems, although I doubt anyone relies on the 'bad write retry' error). What do you think? I'd be ready to write the patch for the set_mode wrapper if you want. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: Hmm, indeed. What you can do, very simply, is cache the getvalue() result once you have generated it. After some thoughts, it's not really an option: my cStringIO.StringIO buffer is, well a buffer. To append data to the buffer, I call buffer.write(). When I've got a chance to send data over the socket (remember, it's async, so I don't really know when it's going to happen), I call buffer.getvalue(). If socket.write() returns zero byte written, I'll have to wait until I get another chance to send my buffer. But in the meantime, some more data might get appended to the buffer, and the string returned by getvalue() will be different from the first call (and thus, I can't really cache it). I could find some tricks (like using multiple buffers), but it would be ugly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment:
The following test case exhibits the bug, but I'm not sure it will fail every
time as it depends on 2 things:
- your connection speed (I guess)
- I used the following trick to have 2 identical strings with a different id
(memory address):
data = (('xx'[0] + 'xx'[1:])*1, ('xx'[0] + 'xx'[1:])*1)
I'm not sure it will work all the time though.
--
Added file: http://bugs.python.org/file16669/test_ssl.py.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8240
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: You're right about the assert, I've just uploaded a new patch. In non-blocking mode, ssl_socket.send(data) will return either 0 (which means nothing was sent, you'll have to try again), or len(data) when everything was sent. It can't return anything inbetween. This is because SSL_MODE_ENABLE_PARTIAL_WRITE is not enabled. In my opinion, SSL_MODE_ENABLE_PARTIAL_WRITE should probably be enabled, although I don't know if it would have any consequence on existing code. Note that _ssl.c header has: XXX should partial writes be enabled, SSL_MODE_ENABLE_PARTIAL_WRITE? However, it's totally unrelated to our bug. Issue #8222 is also unrelated since SSL_MODE_AUTO_RETRY only applies to blocking sockets. By the way, this bug was triaged test needed. Am I missing anything? This is my first reported bug, I'm not sure about the process. -- Added file: http://bugs.python.org/file16670/test_ssl.py.patch.v2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: I forgot to talk about the conditions in which I stumbled upon that bug. I use a cStringIO.StringIO as a send buffer. When the socket is ready to send data, I call ssl_socket.send(send_buffer.getvalue()). Unfortunately, two consecutive calls to send_buffer.getvalue() may return a different object (i.e. a string with a different memory address). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: r.david.murray: ah, sure :) However, I'm not sure a test case is absolutely required for this issue for two reasons: - the fix is trivial: it's a one-liner that enables a SSL mode that explicitely authorizes SSL_write to be called a second time with a a different memory pointer than the first time. Since memory pointers are opaque to Python programmers anyway, I doubt it could break code (unless you'd expect the failure, of course :) ) - tests about SSL in non-blocking mode are almost inexistant, I think. The only one I could find tests the handshake. See issue #3890 for instance. Probably because writing tests in non-blocking mode isn't easy. However, my test may be correct, I'm just not sure it will pass everywhere :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: pitrou: that's debatable, since the Python programmer has no control over memory pointers. As I said, I have a cStringIO buffer, and two consecutive calls to buffer.getvalue() yield different objects. What can I do about it? I think it's a rather sane scenario, and I don't feel I'm doing anything wrong. If you think the programmer should be alerted about it, however, then we should at least say it explicitely in the documentation and probably return an explicit Python error. I had to google quite a bit before finding out what this error meant: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8240] ssl.SSLSocket.write may fail on non-blocking sockets
Cyril c...@excellency.fr added the comment: Switching to a documentation issue is fine to me. Indeed I can just cache the result of StringIO.getvalue(), although it feels a bit crude. I won't be able to create a documentation patch since English is not my primary language. While you're at it, the doc says about SSLSocket.write: Returns the number of bytes written. It actually either returns 0 or len(data), at least as long as we don't have SSL partial writes. That's a different behaviour from regular sockets, and I had to look in _ssl.c to figure out why I never had values inbetween. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8240 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
