[issue12810] Remove check for negative unsigned value in socketmodule.c
New submission from Joel : fixes the following warning: cpython/Modules/socketmodule.c:1748:74: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (cmsgh == NULL || msg->msg_control == NULL || msg->msg_controllen < 0) -- files: bad_unsigned_check.patch keywords: patch messages: 142674 nosy: shenki priority: normal severity: normal status: open title: Remove check for negative unsigned value in socketmodule.c Added file: http://bugs.python.org/file22988/bad_unsigned_check.patch ___ Python tracker <http://bugs.python.org/issue12810> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12812] libffi does not build with clang on amd64
New submission from Joel : tl;dr libffi needs to be updated so Python will build with clang on Linux on amd64 libffi, part of ctypes, has a test for PC relative relocations. It assembles a assembler file with CC, and looks for the string "warning" in the output. clang produces harmless warning unrelated to the assembly operation, but the test causes HAVE_AS_X86_PCREL to be left unset. When trying to assemble Modules/_ctypes/libffi/src/x86/unix64.S, the compiler finds invalid syntax and the build fails. This was raised on the libffi mailing list, with a proposed patch http://sourceware.org/ml/libffi-discuss/2011/msg00024.html The patch appears to be part of upstream libffi: https://github.com/atgreen/libffi/blob/master/configure.ac#L296 So perhaps the best fix would be to update the version of libffi in the tree. -- components: Build messages: 142686 nosy: shenki priority: normal severity: normal status: open title: libffi does not build with clang on amd64 ___ Python tracker <http://bugs.python.org/issue12812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12810] Remove check for negative unsigned value in socketmodule.c
Joel added the comment: My full name is Joel Stanley, and yep, please add me to Misc/ACKS. -- ___ Python tracker <http://bugs.python.org/issue12810> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46070] _PyImport_FixupExtensionObject() regression causing a crash in subintepreters
Joel Uckelman added the comment: I have this happening on Linux with a Flask app after upgrading from Fedora 34 to 35. libpython keeps crashing httpd. I see this from journalctl: #0 0x7fd899baa801 PyObject_Malloc (libpython3.10.so.1.0 + 0xf7801) #1 0x7fd899baab47 PyUnicode_New (libpython3.10.so.1.0 + 0xf7b47) #2 0x7fd899bb9aae _PyUnicode_FromUCS1 (libpython3.10.so.1.0 + 0x106aae) #3 0x7fd899bb9323 r_object (libpython3.10.so.1.0 + 0x106323) #4 0x7fd899bb8d46 r_object (libpython3.10.so.1.0 + 0x105d46) #5 0x7fd899bb90b4 r_object (libpython3.10.so.1.0 + 0x1060b4) #6 0x7fd899bb8d65 r_object (libpython3.10.so.1.0 + 0x105d65) #7 0x7fd899bb9088 r_object (libpython3.10.so.1.0 + 0x106088) #8 0x7fd899bb8e33 r_object (libpython3.10.so.1.0 + 0x105e33) #9 0x7fd899bb9088 r_object (libpython3.10.so.1.0 + 0x106088) #10 0x7fd899c35c28 read_object (libpython3.10.so.1.0 + 0x182c28) #11 0x7fd899c48f56 marshal_loads (libpython3.10.so.1.0 + 0x195f56) #12 0x7fd899bc88d7 cfunction_vectorcall_O (libpython3.10.so.1.0 + 0x1158d7) #13 0x7fd899bc0c80 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x10dc80) #14 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #15 0x7fd899bbccba _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x109cba) #16 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #17 0x7fd899bbbd6d _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108d6d) #18 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #19 0x7fd899bbbd6d _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108d6d) #20 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #21 0x7fd899bbbac2 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108ac2) #22 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #23 0x7fd899bbbac2 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108ac2) #24 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #25 0x7fd899bc8a9e object_vacall (libpython3.10.so.1.0 + 0x115a9e) #26 0x7fd899bd247c _PyObject_CallMethodIdObjArgs (libpython3.10.so.1.0 + 0x11f47c) #27 0x7fd899bd21d7 PyImport_ImportModuleLevelObject (libpython3.10.so.1.0 + 0x11f1d7) #28 0x7fd899bbfc8e _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x10cc8e) #29 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #30 0x7fd899c360d4 PyEval_EvalCode (libpython3.10.so.1.0 + 0x1830d4) #31 0x7fd899c3d091 builtin_exec (libpython3.10.so.1.0 + 0x18a091) #32 0x7fd899bc94b0 cfunction_vectorcall_FASTCALL (libpython3.10.so.1.0 + 0x1164b0) #33 0x7fd899bc2209 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x10f209) #34 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #35 0x7fd899bc0c80 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x10dc80) #36 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #37 0x7fd899bbbd6d _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108d6d) #38 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #39 0x7fd899bbbac2 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108ac2) #40 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #41 0x7fd899bbbac2 _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x108ac2) #42 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #43 0x7fd899bc8a9e object_vacall (libpython3.10.so.1.0 + 0x115a9e) #44 0x7fd899bd247c _PyObject_CallMethodIdObjArgs (libpython3.10.so.1.0 + 0x11f47c) #45 0x7fd899bd21d7 PyImport_ImportModuleLevelObject (libpython3.10.so.1.0 + 0x11f1d7) #46 0x7fd899bbfc8e _PyEval_EvalFrameDefault (libpython3.10.so.1.0 + 0x10cc8e) #47 0x7fd899bba984 _PyEval_Vector (libpython3.10.so.1.0 + 0x107984) #48 0x7fd899c360d4 PyEval_EvalCode (libpython3.10.so.1.0 + 0x1830d4) #49 0x7fd899c36006 exec_code_in_module (libpython3.10.so.1.0 + 0x183006) #50 0x7fd899ba33e7 PyImport_ExecCodeModuleObject (libpython3.10.so.1.0 + 0xf03e7) #51 0x7fd899ba3482 PyImport_ExecCodeModuleWithPathnames (libpython3.10.so.1.0 + 0xf0482) #52 0x7fd899e0f542 wsgi_load_source.lto_priv.0 (mod_wsgi_python3.so + 0x17542) #53 0x7fd899e107ed wsgi_execute_script.lto_priv.0 (mod_wsgi_python3.so + 0x187ed) #54 0x7fd899e1b0f6 wsgi_daemon_thread (mod_wsgi_python3.so + 0x230f6) #55 0x7fd89ab52a87 start_thread (libc.so.6 + 0x8da87) #56 0x7fd89abd7640 __clone3 (libc.so.6 + 0x112640) I see this in /var/log/httpd/ssl_error_log: [Sat Jan 01 05:17:21.248640 2022] [wsgi:error] [pid 257749:tid 257758] Exception
[issue7352] python2.6-config --ldflags out of /usr and missing -L
Joel Brobecker added the comment: More update on this patch: It's incomplete, and possibly wrong, unfortunately. The issue that someone else noticed is that it does not handle the case when Python was configured with --libdir=...; and I think that the default lib dir on platforms such as Windows and Darwin might be different from the traditional /lib as well, although I don't remember anymore (I did the investigation a couple of weeks ago). I tried to find simple ways to update the script to make it work with a different libdir, but to no avail. :-( I think that the best option is to enhance the sysconfig module to return the relocated lib path, but the problem is that the script would no longer work with older versions of Python (as older versions of Python would be missing that function). Perhaps one possible acceptable compromise is to call that function only when available and default to the old behavior otherwise. So it'd still be working as well as it does now with older versions of Python, while being slightly better with newer ones... Just some thoughts... -- ___ Python tracker <http://bugs.python.org/issue7352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11751] Increase distutils/filelist test coverage
Changes by Joel Luellwitz : -- versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue11751> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11754] Changed test to check calculated constants in test_string.py
Joel Luellwitz added the comment: Make a slight change to diff file. -- nosy: +JoelLuellwitz Added file: http://bugs.python.org/file21521/test_calculated_constants.diff ___ Python tracker <http://bugs.python.org/issue11754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3370] importing with_statement causes exec to raise syntax error on block that doesn't end with a newline
Joel Madigan <[EMAIL PROTECTED]> added the comment: Confirmed in Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32) Seems to be fixed in 2.6b1. -- nosy: +dochoncho ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3370> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5584] json.loads(u'3.14') fails unexpectedly (minor scanner bug)
Joel Pearson added the comment:
The fix for this bug was included in r72194.
I verified that the fix is included in trunk, the release31-maint branch, and
the py3k branch. I also verified that json.loads(u'3.14') works in 2.7a3, and
that json.loads('3.14') works in 3.1.1, so I believe that this bug can be
closed.
--
nosy: +joel.pearson
___
Python tracker
<http://bugs.python.org/issue5584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2791] subprocess.py leaks fd in communicate
New submission from Joel Rosdahl <[EMAIL PROTECTED]>: The optimization in SVN rev 38556 seems to have changed Popen.communicate's behavior when stdout is subprocess.PIPE (and maybe for other cases as well). See the attached file. In Python 2.4.5, all three counts are the same. In Python 2.5.2, the middle count has increased by 1. In other words: A file descriptor is leaked until the last reference to the Popen instance is dropped. -- components: Library (Lib) files: subprocess-fd-problem.py messages: 66415 nosy: jrosdahl severity: normal status: open title: subprocess.py leaks fd in communicate type: resource usage versions: Python 2.5 Added file: http://bugs.python.org/file10221/subprocess-fd-problem.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2791> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: I'm kind of in agreement with Mark on this, actually. I came across this problem when examining some threaded code that was clearly not working as intended, but was reporting success. Figuring out why that was was not easy. The code had been hastily ported to a multi-threaded version from an iterative version by my predecessor, and neither of us had enough familiarity with Python threads to realize what the problem was. The whole point of having exceptions is that it gives you a way of knowing when errors happen without having to add a bunch of extra error checking to your own code. It rather defeats the purpose if code can silently fail while still throwing exceptions, and we have to add extra code to handle special cases like this where they are ignored. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44876] .replace functions in datetime do not call __new__
New submission from Joel Gibson : I've come here while investigating a segfault when datetime.replace(...) was called with a Pandas Timestamp object: https://github.com/pandas-dev/pandas/issues/42305 The Python implementation of datetime.replace https://github.com/python/cpython/blob/03e5647ab07c7d2a05094fc3b5ed6eba6fc01349/Lib/datetime.py#L1823 is polymorphic, in the sense that if a custom object like pd.Timestamp is passed in, a pd.Timestamp will come out rather than a datetime. This works just fine (copying and using Python code makes this segfault disappear). The C implementation is also polymorphic https://github.com/python/cpython/blob/03e5647ab07c7d2a05094fc3b5ed6eba6fc01349/Modules/_datetimemodule.c#L5845 but I think that something in the C implementation is wrong: eventually tp_alloc gets called for the passed type, but never tp_new, and then afterwards the custom type is treated just like a regular datetime. In the pd.Timestamp case, there are some extra fields that only get set in the __new__ method, leading to a segfault later when they're accessed. I'm not familiar enough with the C/CPython interface (especially object setup and initialisation) to tell where a fix for this should go, I would assume that the line https://github.com/python/cpython/blob/03e5647ab07c7d2a05094fc3b5ed6eba6fc01349/Modules/_datetimemodule.c#L5872 should be replaced by a call to PyObject_new(Py_TYPE(self), ...), or something similar. This also affects date.replace and time.replace. -- components: Library (Lib) messages: 399295 nosy: joelgibson priority: normal severity: normal status: open title: .replace functions in datetime do not call __new__ type: behavior ___ Python tracker <https://bugs.python.org/issue44876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31456] SimpleCookie fails to parse any cookie if an entry has whitespace in the name
Change by Joel Rosdahl : -- nosy: +Joel Rosdahl ___ Python tracker <https://bugs.python.org/issue31456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40499] asyncio.wait documentation on non-emptiness requirement lost in bpo-33649
New submission from Joel Rosdahl : bpo-21596 documented that the sequence of futures passed to asyncio.wait must not be empty: The sequence *futures* must not be empty. This note was however lost in the bpo-33649 commit (3faaa8857a42a36383bb18425444e597fc876797). -- assignee: docs@python components: Documentation messages: 368041 nosy: Joel Rosdahl, docs@python priority: normal severity: normal status: open title: asyncio.wait documentation on non-emptiness requirement lost in bpo-33649 versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40499] asyncio.wait documentation on non-emptiness requirement lost in bpo-33649
Change by Joel Rosdahl : -- keywords: +patch nosy: +jrosdahl nosy_count: 2.0 -> 3.0 pull_requests: +19211 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19900 ___ Python tracker <https://bugs.python.org/issue40499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21596] asyncio.wait fails when futures list is empty
Change by Joel Rosdahl : -- nosy: +jrosdahl nosy_count: 8.0 -> 9.0 pull_requests: +19212 pull_request: https://github.com/python/cpython/pull/19900 ___ Python tracker <https://bugs.python.org/issue21596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33649] asyncio docs overhaul
Change by Joel Rosdahl : -- nosy: +jrosdahl nosy_count: 14.0 -> 15.0 pull_requests: +19213 pull_request: https://github.com/python/cpython/pull/19900 ___ Python tracker <https://bugs.python.org/issue33649> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42959] AttributeError: module 'signal' has no attribute 'SIGHUP'
New submission from Joel Ewaldo : I have already tried uninstalling and reinstalling python 3.7.9 via the 64-bit installer on the official python website. Also, I am on the latest version of windows. I have also made sure that signal.py was not a file in my directory and when I import _signal followed with print(dir(_signal)), it returns ['CTRL_BREAK_EVENT', 'CTRL_C_EVENT', 'NSIG', 'SIGABRT', 'SIGBREAK', 'SIGFPE', 'SIGILL', 'SIGINT', 'SIGSEGV', 'SIGTERM', 'SIG_DFL', 'SIG_IGN', '__doc__', '__loader__', '__name__', '__package__', '__spec__', 'default_int_handler', 'getsignal', 'set_wakeup_fd', 'signal']. -- components: Windows files: unknown (2).png messages: 385227 nosy: ametatheton2, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: AttributeError: module 'signal' has no attribute 'SIGHUP' type: compile error versions: Python 3.9 Added file: https://bugs.python.org/file49748/unknown (2).png ___ Python tracker <https://bugs.python.org/issue42959> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4773] HTTPMessage not documented and has inconsistent API across 2.6/3.0
Joel Verhagen added the comment:
There is a difference in what HTTPResponse.getheaders() returns.
Python 2.7.2 (default, Jun 12 2011, 14:24:46) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import httplib
>>> c = httplib.HTTPConnection('www.joelverhagen.com')
>>> c.request('GET', '/sandbox/tests/cookies.php')
>>> c.getresponse().getheaders()
[('content-length', '0'), ('set-cookie', 'test_cookie1=foobar; expires=Fri,
02-Mar-2012 16:54:15 GMT, test_cookie2=barfoo; expires=Fri, 02-Mar-2012
16:54:15 GMT'), ('vary', 'Accept-Encoding'), ('server', 'Apache'), ('date',
'Fri, 02 Mar 2012 16:53:15 GMT'), ('content-type', 'text/html')]
Python 3.2.2 (default, Sep 4 2011, 09:07:29) [MSC v.1500 64 bit (AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from http import client
>>> c = client.HTTPConnection('www.joelverhagen.com')
>>> c.request('GET', '/sandbox/tests/cookies.php')
>>> c.getresponse().getheaders()
[('Date', 'Fri, 02 Mar 2012 16:56:40 GMT'), ('Server', 'Apache'),
('Set-Cookie', 'test_cookie1=foobar; expires=Fri, 02-Mar-2012 16:57:40 GMT'),
('Set-Cookie', 'test_cookie2=barfoo; expires=Fri, 02-Mar-2012 16:57:40 GMT'),
('Vary', 'Accept-Encoding'), ('Content-Length', '0'), ('Content-Type',
'text/html')]
As you can see, in 2.7.2 HTTPResponse.getheaders() in 2.7.2 joins headers with
the same name by ", ". In 3.2.2, the headers are kept separate and two or more
2-tuples.
This causes problems if you convert the list of 2-tuples to a dict, because the
keys collide (causing all but one of the values associated the non-unique keys
to be overwritten). It looks like this problem is caused by using the email
header parser (which keeps the keys and values as separate 2-tuples). In Python
2.7.2, the HTTPMessage.addheader(...) function does the comma-separating.
Is this API change intentional? Should HTTPResponse.getheaders() comma-separate
the values like the HTTPResponse.getheader(...) function (in both 2.7.2 and
3.2.2)?
See also:
https://github.com/shazow/urllib3/issues/3#issuecomment-3008415
--
nosy: +joel.verhagen
___
Python tracker
<http://bugs.python.org/issue4773>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14556] telnetlib Telnet.expect fails with timeout=0
New submission from Joel Lovinger :
In Python 2.4.3 a Telnet.expect with timeout=0 would always make at least one
call to Telnet.fill_rawq if a match couldn't be found and the connection was
open.
In Python 2.7.1/2.7.3 Telnet.expect with timeout=0 breaks before any call to
Telnet.fill_rawq if a match isn't found in already read raw/cooked data.
Expected behavior is that on timeout=0 at least one non-blocking attempt should
be made to read from the connection when necessary to fulfill a match.
>From code inspection (including Python 2.7.3) timeout behavior was modified to
>provide an overall elapsed timeout instead of passing unmodified timeout to
>each select resulting in the failure.
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(-1, None, '')
>>>
Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> import time
>>> tn = Telnet("scn.org", 23)
>>> time.sleep(5) # short wait for data to be available
>>> tn.expect(['.{16}'], 0)
(0, <_sre.SRE_Match object at 0x01752410>, '\r\nSeattle Communit')
>>>
--
components: Library (Lib)
messages: 158096
nosy: Joel.Lovinger
priority: normal
severity: normal
status: open
title: telnetlib Telnet.expect fails with timeout=0
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue14556>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14556] telnetlib Telnet.expect fails with timeout=0
Joel Lovinger added the comment: Quick response! Based on review of Telnet.expect in Python 2.4.3 and Python 2.7.1/2.7.3. In Python 2.4.3 the timeout is passed unmodified on each loop iteration to the underlying select to get more data for a potential match. Iteration only ends on EOF, select timeout with no rx, or match. A timeout=0 received data, without blocking, until no more data or a match was found. Unfortunately this implementation can extend the timeout indeterminately if the connection consistently has data for each select but no match is made. Imagine with timeout=10 and a byte coming in every 5 seconds. Select will always succeed and continue to iterate. Could even happen with timeout=0 if match processing takes long enough for each iteration (high system load, long input buffer, complicated reg ex, etc). Python 2.7.1 keeps track of overall elapsed time in Telnet.expect itself and explicitly drops out when it exceeds the timeout. Further passes (timeout-elapsed) as the timeout to select. Works to ensure an expect never exceeds its timeout, but breaks the case where timeout=0 can read non-blocking to find a match. -- ___ Python tracker <http://bugs.python.org/issue14556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14556] telnetlib Telnet.expect fails with timeout=0
Joel Lovinger added the comment: 2.4 behavior, "time out if there is no more data for X seconds", only worked as expected in the case of timeout=0. Any other timeout could result in indefinite extension and needed fixing. 2.7 behavior, "time out if there is no match for X seconds" fixes timeout!=0 cases while breaking for timeout=0. Can't get former behavior on timeout=0 in 2.7 using socket.settimeout(). Call to socket.recv() then throws a timeout exception which isn't caught by Telnet.expect. I think fixing timeout=0 will require a patch to Telnet.expect. The simplest would likely be to insert a "very eager" type read to grab all data without blocking before entering the match loop. Won't need to modify existing timeout logic and sidesteps any new corner cases on select/recv iteration. The only functional side effect (other than moving storage in some cases from the socket to the Telnet object) is on greedy RE that will have more data to match. Documentation already warns against greedy RE as non-deterministic so hopefully not an issue. -- ___ Python tracker <http://bugs.python.org/issue14556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Joel Hillacre added the comment: > Ping the issue again next week if I don't get to it this weekend. I am a week late, but here is a ping. -- ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30788] email.policy.SMTP.fold() issue with long filenames with spaces
New submission from Joel Hillacre:
Found an issue in email.policy.SMTP.fold on "Content-Disposition" headers for
long filenames with spaces. Managed to simply the issue to a test case as
follows:
>>> from email.policy import SMTP; SMTP.fold('Content-Disposition',
>>> 'attachment; filename="{}"'.format('1234 67890' + '1234567890' * 6))
Below are the tracebacks various python versions produces for this code. I
think that the difference between python 3.5 - 3.6 and 3.7 are related to the
fix in bpo-30532.
Python 3.6.1 (default, Apr 7 2017, 09:32:32) & Python 3.5.3 (default, Jan 17
2017, 14:34:36)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.6/email/policy.py", line 183, in fold
return self._fold(name, value, refold_binary=True)
File "/usr/lib64/python3.6/email/policy.py", line 213, in _fold
return self.header_factory(name, ''.join(lines)).fold(policy=self)
File "/usr/lib64/python3.6/email/headerregistry.py", line 255, in fold
return header.fold(policy=policy)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 300, in fold
self._fold(folded)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 1228, in _fold
rest._fold(folded)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 347, in _fold
if folded.append_if_fits(part):
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 149, in
append_if_fits
token._fold(self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 338, in _fold
if folded.append_if_fits(part, tstr):
... last 4 lines repeated 482 more times ...
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 149, in
append_if_fits
token._fold(self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 325, in _fold
tstr = str(part)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
__str__
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
__str__
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
__str__
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 196, in
return ''.join(str(x) for x in self)
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 633, in
__str__
return quote_string(''.join(str(x) for x in self))
File "/usr/lib64/python3.6/email/_header_value_parser.py", line 633, in
return quote_string(''.join(str(x) for x in self))
RecursionError: maximum recursion depth exceeded while getting the str of an
object
Python 3.7.0a0 (heads/master:e613e6add5, Jun 27 2017, 12:17:18)
Traceback (most recent call last):
File "", line 1, in
File "/home/joel/PycharmProjects/cpython/Lib/email/policy.py", line 183, in
fold
return self._fold(name, value, refold_binary=True)
File "/home/joel/PycharmProjects/cpython/Lib/email/policy.py", line 213, in
_fold
return self.header_factory(name, ''.join(lines)).fold(policy=self)
File "/home/joel/PycharmProjects/cpython/Lib/email/headerregistry.py", line
255, in fold
return header.fold(policy=policy)
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 300, in fold
self._fold(folded)
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 1226, in _fold
rest._fold(folded)
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 345, in _fold
if folded.append_if_fits(part):
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 145, in append_if_fits
ws = token.pop_leading_fws()
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 272, in pop_leading_fws
return self[0].pop_leading_fws()
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 272, in pop_leading_fws
return self[0].pop_leading_fws()
File "/home/joel/PycharmProjects/cpython/Lib/email/_header_value_parser.py",
line 270, in pop_leading_fws
if self[0].token_type == 'fws':
IndexError: list index out of range
Note that the following examp
[issue30788] email.policy.SMTP.fold() issue for long filenames with spaces
Changes by Joel Hillacre : -- title: email.policy.SMTP.fold() issue with long filenames with spaces -> email.policy.SMTP.fold() issue for long filenames with spaces ___ Python tracker <http://bugs.python.org/issue30788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Changes by Joel Hillacre : -- pull_requests: +2662 ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Changes by Joel Hillacre : -- pull_requests: +2663 ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30788] email.policy.SMTP.fold() issue for long filenames with spaces
Changes by Joel Hillacre : -- pull_requests: +2688 ___ Python tracker <http://bugs.python.org/issue30788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30788] email.policy.SMTP.fold() issue for long filenames with spaces
Joel Hillacre added the comment: Just wanted to ping this and see if there was someone available to review my PR associated with this issue. -- ___ Python tracker <http://bugs.python.org/issue30788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30788] email.policy.SMTP.fold() issue for long filenames with spaces
Joel Hillacre added the comment: I just took a quick peek at your PR to see if a similar test exists from this bug and it is looking good. Thanks for your work. -- ___ Python tracker <https://bugs.python.org/issue30788> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
New submission from Joel Hillacre:
I am encountering a ResourceWarning about an unclosed socket when getting a non
220 response during connect() in __init__() of smtplib.SMTP. Attached are a
client script causing this warning for me, a server script to cause the client
to the warning and a patch that fixes the warning for me. My python version is
Python 3.6.1 (default, Apr 7 2017, 09:32:32) [GCC 4.8.5 20150623 (Red Hat
4.8.5-11)] on linux. I had found previous related issue with similar symptom
and remedy in issue #21641.
$ python3.6 test_server.py
connected by ('127.0.0.1', 53630)
$
$ python3.6 test_client.py
Traceback (most recent call last):
File "test_client.py", line 2, in
smtp = smtplib.SMTP('127.0.0.1', 8025)
File "/usr/lib64/python3.6/smtplib.py", line 253, in __init__
raise SMTPConnectError(code, msg)
smtplib.SMTPConnectError: (554, b'Nope.')
/usr/lib64/python3.6/socket.py:657: ResourceWarning: unclosed
$
RFC 2821 states that servers responding with non 220 greetings must not close
the connection. It is this behaviour that test_server.py is using to trigger
the warning in test_client.py.
RFC 2821 Section 3.1 Paragraph 3
https://tools.ietf.org/html/rfc2821#section-3.1
'... a 554 response MAY be given in the initial connection opening message
instead of the 220. A server taking this approach MUST still wait
for the client to send a QUIT (see section 4.1.1.10) before closing
the connection and SHOULD respond to any intervening commands with
"503 bad sequence of commands".'
The ResourceWarning is no longer caused for me after applying this change.
--
components: Library (Lib)
files: smtplib.patch
keywords: patch
messages: 293905
nosy: jhillacre
priority: normal
severity: normal
status: open
title: smtplib leaves open sockets around if SMTPConnectError is raised in
__init__
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file46873/smtplib.patch
___
Python tracker
<http://bugs.python.org/issue30394>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
Changes by Joel Hillacre : Added file: http://bugs.python.org/file46874/test_server.py ___ Python tracker <http://bugs.python.org/issue30394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
Changes by Joel Hillacre : Added file: http://bugs.python.org/file46875/test_client.py ___ Python tracker <http://bugs.python.org/issue30394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
Changes by Joel Hillacre : -- pull_requests: +1796 ___ Python tracker <http://bugs.python.org/issue30394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
Joel Hillacre added the comment: > Joel, our patch system has moved to GitHub. Mind to turn your patch into a PR? I have opened a PR now. I took a look at changing my example into a test. I am not sure how to test for a lack of warning. Closest test I found was BadHELOServerTests in test_smtplib.py, but using mock_socket would not cause the warning from socket.py. -- ___ Python tracker <http://bugs.python.org/issue30394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30394] smtplib leaves open sockets around if SMTPConnectError is raised in __init__
Joel Hillacre added the comment: r.david.murray, How would a test would have a reference to after an exception in the smtplib.SMTP.__init__()? -- ___ Python tracker <http://bugs.python.org/issue30394> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Changes by Joel Hillacre : -- pull_requests: +1968 ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Joel Hillacre added the comment: I added a pull request that causes Chris's test to pass. I can confirm that the Chris's was not pass for me on master branch. -- nosy: +jhillacre ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30532] email.policy.SMTP.fold() mangles long headers
Joel Hillacre added the comment: Rebased the github PR on latest master to get the windows build passing CI. Is there anything I need to do to keep the PR moving? -- ___ Python tracker <http://bugs.python.org/issue30532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
New submission from Joel Croteau : I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen anyone use dotted octal format, it is actually specifically forbidden by RFC 3986 (https://tools.ietf.org/html/rfc3986#section-7.4), and it means that the ipaddress module throws exceptions on many perfectly valid IP addresses just because they have leading zeroes. Since the module doesn't support dotted octal or dotted hex anyway, this check seems a little pointless. If nothing else, there should be a way to disable this check by specifying that your IPs are in fact dotted decimal, otherwise it seems like it's just making you have to do extra parsing work or just write your own implementation. -- components: Library (Lib) messages: 338514 nosy: Joel Croteau priority: normal severity: normal status: open title: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal type: behavior versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue36384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
New submission from Joel Croteau : This has been commented on numerous times by others (https://stackoverflow.com/questions/2829329/catch-a-threads-exception-in-the-caller-thread-in-python, http://benno.id.au/blog/2012/10/06/python-thread-exceptions, to name a few), but there is no in-built mechanism in threading to catch an unhandled exception thrown by a thread. The default behavior of dumping to stderr is completely useless for error handling in many scenarios. Solutions do exist, but I have yet to see one that is not exceptionally complicated. It seems like checking for exceptions should be a very basic part of any threading library. The simplest solution would be to just have the Thread store any unhandled exceptions and have them raised by Thread.join(). There could also be additional methods to check if exceptions were raised. -- components: Library (Lib) messages: 340520 nosy: Joel Croteau priority: normal severity: normal status: open title: threading.Thread should have way to catch an exception thrown within versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: I agree that we should not change the default behavior of Thread.join(), as that would break existing code, but there are plenty of other ways to do this. I see a couple of possibilities: 1. Add an option to the Thread constructor, something like raise_exc, that defaults to False, but when set to True, causes join() to raise any exceptions. 2. (Better, IMO) Add this option to the join() method instead. 3. Create a new method, join_with_exc(), that acts like join() but raises exceptions from the target. 4. (Should probably do this anyway, regardless of what else we do) Add a new method, check_exc(), that checks if any unhandled exceptions have occurred in the thread and returns and/or raises any that have. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36666] threading.Thread should have way to catch an exception thrown within
Joel Croteau added the comment: Yes, I know there are workarounds for it, I have seen many, and everyone seems to have their own version. I'm saying we shouldn't need workarounds though–this should be built in functionality. Ideally, dropping an exception should never be default behavior, but I understand not wanting to break existing code, that's why I'm saying add additional functionality to make these checks easier and not require hacky, un-pythonic wrappers and other methods to find out if your code actually worked. -- ___ Python tracker <https://bugs.python.org/issue3> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36717] Allow retrieval of return value from the target of a threading.Thread
New submission from Joel Croteau : It would be nice if, after a threading.Thread has completed its run, it were possible to retrieve the return value of the target function. You can do this currently by setting a variable from your target or by subclassing Thread, but this should really be built in. My suggested changes: * Add an attribute to Thread, retval, initially set to None, that contains the return value of the target after a successful completion. * Thread.run() should set self.retval to the return value of the target upon completion, and also return this value. * Thread.join() should return self.retval after a successful completion. If you're not using Thread.join(), you can directly access Thread.retval to get the return result after a successful run. Thread.run() and Thread.join() both return None in all cases now, so I think a change in their return value would have minimal if any effect on existing code. -- components: Library (Lib) messages: 340815 nosy: Joel Croteau2 priority: normal severity: normal status: open title: Allow retrieval of return value from the target of a threading.Thread type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue36717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25433] whitespace in strip()/lstrip()/rstrip()
Joel Johnson added the comment: I have started working on this and will have a pull request submitted by the end of the week. The term "whitespace" appears in several contextual situations throughout the documentation. While all situations would benefit from the definition of "whitespace" contained in the str.isspace() documentation, not all of the situations would benefit from a link to str.isspace() whose primary goal is to document the str.isspace() function and not to provide a global definition of what a whitespace character is. Therefore I suggest the documentation of Python 3 create a new glossary definition of "whitespace" (which contains the definition currently in the str.isspace() documentation) and is pointed to wherever the term "whitespace" is used in any documentation related to strings - including this specific case of strip()/lstrip()/rstrip(). -- nosy: +joel.johnson ___ Python tracker <https://bugs.python.org/issue25433> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16516] argparse types (and actions) must be hashable
Joel Nothman added the comment: Clearly this is not in high demand -- ___ Python tracker <https://bugs.python.org/issue16516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33875] Allow dynamic password evaluation in pypirc configuration file.
New submission from Joel Perras : In its current implementation, a user is required to provide their cleartext PyPi password in their .pypirc configuration file for authenticated interactions with PyPi servers to succeed. For hopefully obvious reasons, this is sub-optimal from a security standpoint. In some popular utilities (e.g. msmtp), the ability to provide a `passwordeval` field is made optional to the user. The value to this field is executed by the OS-dependent shell, and the return value is then used as the password. For example, instead of this: ``` index-servers= pypi [pypi] username=jperras password=mygreatpassword ``` we can instead have this: ``` index-servers= pypi [pypi] username=jperras passwordeval="gpg --quiet --for-your-eyes-only --no-tty --decrypt ~/.pypipwd.gpg" ``` -- components: Distutils messages: 319699 nosy: dstufft, eric.araujo, jperras priority: normal severity: normal status: open title: Allow dynamic password evaluation in pypirc configuration file. type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33875] Allow dynamic password evaluation in pypirc configuration file.
Change by Joel Perras : -- keywords: +patch pull_requests: +7348 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33875> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34828] sqlite.iterdump does not work for (most) databases with autoincrement
New submission from Joel Klimont :
There is a bug in sqlite3/dump.py when wanting to dump databases that use
autoincrement in one or more tables.
The problem is that the iterdump command assumes that the table
"sqlite_sequence" is present in the new database in which the old one is dumped
into.
>From the sqlite3 documentation:
"SQLite keeps track of the largest ROWID using an internal table named
"sqlite_sequence". The sqlite_sequence table is created and initialized
automatically whenever a normal table that contains an AUTOINCREMENT column is
created. The content of the sqlite_sequence table can be modified using
ordinary UPDATE, INSERT, and DELETE statements."
Source: https://sqlite.org/autoinc.html#the_autoincrement_keyword
Example:
BEGIN TRANSACTION;
CREATE TABLE "posts" (
id int primary key
);
INSERT INTO "posts" VALUES(0);
CREATE TABLE "tags" (
id integer primary key autoincrement,
tag varchar(256) unique,
post int references posts
);
INSERT INTO "tags" VALUES(NULL, "test", 0);
COMMIT;
The following code should work but because of the assumption that
"sqlite_sequence" exists it will fail:
>> import sqlite3
>> cx = sqlite3.connect("test.db")
>> for i in cx.iterdump():
>>print i
>> cx2 = sqlite3.connect(":memory:")
>> query = "".join(line for line in cx.iterdump())
>> cx2.executescript(query)
Exception:
Traceback (most recent call last):
File "/home/test.py", line 10, in
cx2.executescript(query)
sqlite3.OperationalError: no such table: sqlite_sequence
Here is the ouput of cx.iterdrump()
BEGIN TRANSACTION;
CREATE TABLE "posts" (
id int primary key
);
INSERT INTO "posts" VALUES(0);
DELETE FROM "sqlite_sequence";
INSERT INTO "sqlite_sequence" VALUES('tags',1);
CREATE TABLE "tags" (
id integer primary key autoincrement,
tag varchar(256) unique,
post int references posts
);
INSERT INTO "tags" VALUES(1,'test',0);
COMMIT;
As you can see the problem is that "DELETE FROM "sqlite_sequence";" and "INSERT
INTO "sqlite_sequence" VALUES('tags',1);" are put into the dump before that
table even exists. They should be put at the end of the transaction. (Like the
sqlite3 command ".dump" does.)
Note that some databases that use autoincrement will work as it could be that a
table with autoincrement is created before the sqlite_sequence commands are put
into the dump.
File: https://github.com/python/cpython/blob/master/Lib/sqlite3/dump.py
I have already forked the repository, written tests etc. and if you want I will
create a pull request.
--
components: Library (Lib)
messages: 326610
nosy: itssme
priority: normal
severity: normal
status: open
title: sqlite.iterdump does not work for (most) databases with autoincrement
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue34828>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34828] sqlite.iterdump does not work for (most) databases with autoincrement
Change by Joel Klimont : -- keywords: +patch pull_requests: +9019 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue34828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34828] sqlite.iterdump does not work for (most) databases with autoincrement
Joel Klimont added the comment: I made the pull request: https://github.com/python/cpython/pull/9621 -- ___ Python tracker <https://bugs.python.org/issue34828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16516] argparse types (and actions) must be hashable
New submission from Joel Nothman:
The argparse documentation states that "type= can take any callable that takes
a single string argument and returns the converted value". The following is an
exception:
>>> import argparse
>>> ap = argparse.ArgumentParser()
>>> ap.add_argument('foo', type={}.get)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/argparse.py", line 1294, in add_argument
type_func = self._registry_get('type', action.type, action.type)
File "/usr/lib/python3/argparse.py", line 1236, in _registry_get
return self._registries[registry_name].get(value, default)
TypeError: unhashable type: 'dict'
Sadly, a method bound to an unhashable type is unhashable! (Of course, is
trivial to use partial or lambda to make any function hashable.)
The offending line in _registry_get is intended to look up named types (or
actions), so it perhaps only relevant for string type= and action= values,
which could be handled explicitly instead of using dict.get(x, x) to handle
both cases. Alternatively, the TypeError could be caught and default returned.
--
components: Library (Lib)
messages: 176040
nosy: bethard, jnothman
priority: normal
severity: normal
status: open
title: argparse types (and actions) must be hashable
type: behavior
versions: Python 2.7, Python 3.4
___
Python tracker
<http://bugs.python.org/issue16516>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1731717] race condition in subprocess module
Joel Martin added the comment: I can reproduce the problem (or at least get the same symptom) by doing this (in 2.4.6, 2.5.4 and 2.6.2): import subprocess, signal signal.signal(signal.SIGCLD, signal.SIG_IGN) subprocess.Popen(['echo','foo']).wait() The echo command completes, but the subprocess command throws the "no child" exception. It seems like the subprocess command should either: - detect that SIGCLD is not set correctly and throw a more informative exception before running the command. - override SIGCLD during the running of the sub-command. Not sure what the UNIX correctness implications of this are. - or allow the child to zombie without throwing an exception. The fact that the programmer has overridden SIGCLD sort of implies that reaping of zombie children has been switched off. I don't have good enough understanding of the underlying implementation to know if this is a reproducer as requested or if this should be a new bug. Please advise and I will file a new bug if requested. This is a follow-up to trying to resolve this problem in the PEP 3143 python-daemon module. See this thread: http://groups.google.com/group/comp.lang.python/browse_thread/thread/9a853d0308c8e55a -- nosy: +kanaka status: pending -> open ___ Python tracker <http://bugs.python.org/issue1731717> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7352] python2.6-config --ldflags out of /usr and missing -L
Joel Brobecker added the comment: GDB can suffer from the same sort of problem. In my case, I picked up a Python binary tarball built on a different machine (without --enable-shared), and the path in -L returned by python-config --ldflags refered to the prefix used at configure time. But, by comparison, --cflags returns the correct include path. To give more context: GDB can be linked against libpython to add python scripting support in GDB. To determine how to compile&link Python in GDB, we have a copy of python-config in GDB, and do "python /path/to/python-config --cflags/ldflags. Because it is often convenient to pick up a binary install, and because this install is not always at the same location as the prefix used at configure time, python-config --ldflags returns a -L with a path that is irrelevant in our case. The attached patch fixes this issue. The patch also fixes the issue originally reported: I think that python-config --ldflags should also print -L/lib in the case where python was configured with --enable-shared. This is necessary when prefix is not a standard location. This was tested with Python 2.5, 2.6, and 2.7, static and shared, by calling the script with --ldflags, and by verifying the output. -- keywords: +patch nosy: +brobecke Added file: http://bugs.python.org/file17910/python-config.diff ___ Python tracker <http://bugs.python.org/issue7352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7352] python2.6-config --ldflags out of /usr and missing -L
Joel Brobecker added the comment: I agree that more testing in head would be useful before possibly considering inclusion in one of the bug-fix releases. Given that this only affects binaries installed at a different location than the configure prefix, this seems hardly critical (and easy to fix locally). -- ___ Python tracker <http://bugs.python.org/issue7352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.M
New submission from Joel Uckelman:
Test case:
import email
import email.policy
txt = '''From: juckel...@strozfriedberg.co.uk
To: (Recipient list suppressed)
Date: Thu, 22 Aug 2013 04:13:02 +
Subject: ADSF-1082
Hey!
'''
msg = email.message_from_string(txt)
msg.get('to')
msg = email.message_from_string(txt, policy=email.policy.default)
msg.get('to')
The second msg.get() throws an IndexError:
Traceback (most recent call last):
File "test.py", line 16, in
print(msg.get('to'))# throws IndexError
File "/usr/lib64/python3.5/email/message.py", line 472, in get
return self.policy.header_fetch_parse(k, v)
File "/usr/lib64/python3.5/email/policy.py", line 153, in header_fetch_parse
return self.header_factory(name, ''.join(value.splitlines()))
File "/usr/lib64/python3.5/email/headerregistry.py", line 586, in __call__
return self[name](name, value)
File "/usr/lib64/python3.5/email/headerregistry.py", line 197, in __new__
cls.parse(value, kwds)
File "/usr/lib64/python3.5/email/headerregistry.py", line 337, in parse
kwds['parse_tree'] = address_list = cls.value_parser(value)
File "/usr/lib64/python3.5/email/headerregistry.py", line 328, in
value_parser
address_list, value = parser.get_address_list(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2336, in
get_address_list
token, value = get_address(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2313, in
get_address
token, value = get_group(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2269, in
get_group
token, value = get_display_name(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 2095, in
get_display_name
token, value = get_phrase(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1770, in
get_phrase
token, value = get_word(value)
File "/usr/lib64/python3.5/email/_header_value_parser.py", line 1745, in
get_word
if value[0]=='"':
IndexError: string index out of range
The docs say that email.policy.default has raise_on_defect set to False, hence
parse errors ought to be reported via EmailMessage.defects, not by throwing an
exception.
--
components: email
messages: 286631
nosy: barry, r.david.murray, uckelman
priority: normal
severity: normal
status: open
title: IndexError thrown on email.message.M
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue29412>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.EmailMessage.get
Changes by Joel Uckelman : -- title: IndexError thrown on email.message.M -> IndexError thrown on email.message.EmailMessage.get ___ Python tracker <http://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.EmailMessage.get
Joel Uckelman added the comment: No dice. I get the same exception with issue27931_v2.patch. I briefly looked at the other two, and don't expect those will help, either. -- ___ Python tracker <http://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Changes by Joel Uckelman : -- title: IndexError thrown on email.message.EmailMessage.get -> IndexError thrown on email.message.Message.get ___ Python tracker <http://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Joel Uckelman added the comment: I'm working on a patch now. -- ___ Python tracker <http://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29412] IndexError thrown on email.message.Message.get
Joel Uckelman added the comment: Here's a patch, complete with tests. If the value is all CFWS, then get_cfws(value)[1], which is what's left after the CFWS is extracted, is the empty string---which is why value[0] throws in this case. -- keywords: +patch Added file: http://bugs.python.org/file46562/29412.patch ___ Python tracker <http://bugs.python.org/issue29412> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied.
New submission from Joel Handwell: While installing python 3.5.1 using chocolatey package manager on Windows 10, I got following message: python3 v3.5.1 WARNING: The names of some imported commands from the module 'chocolateyInstaller' include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb. Downloading python3 64 bit from 'https://www.python.org/ftp/python/3.5.1/python-3.5.1-amd64.exe' Progress: 100% - Saving 28.25 MB of 28.25 MB (29627072/29627072) Download of python3Install.exe (28.25 MB) completed. Installing python3... python3 has been installed. Access to the path 'C:\WINDOWS\system32\Boot\winload.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\Boot\winresume.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\difx64.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyApp.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\DPTopologyAppv2_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\GfxUIEx.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv2_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\Gfxv4_0.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxCUIService.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxEM.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxext.exe.ignore' is denied. Access to the path 'C:\WINDOWS\system32\DriverStore\FileRepository\64dp4256.inf_amd64_9191bdaf5e95d43e\igfxHK.exe.ignore' is denied. -- components: Installation messages: 270209 nosy: joelhandwell priority: normal severity: normal status: open title: Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied. type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27489] Win 10, choco install python gets message: Access to the path 'C:\WINDOWS\system32\**\**.exe.ignore' is denied.
Changes by Joel Handwell : -- resolution: -> third party ___ Python tracker <http://bugs.python.org/issue27489> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26756] fileinput handling of unicode errors from standard input
New submission from Joel Barry:
The openhook for fileinput currently will not be called when the input
is from sys.stdin. However, if the input contains invalid UTF-8
sequences, a program with a hook that specifies errors='replace' will
not behave as expected:
$ cat x.py
import fileinput
import sys
def hook(filename, mode):
print('hook called')
return open(filename, mode, errors='replace')
for line in fileinput.input(openhook=hook):
sys.stdout.write(line)
$ echo -e "foo\x80bar" >in.txt
$ python3 x.py in.txt
hook called
foo�bar
Good. Hook is called, and replacement character is observed.
$ python3 x.py
for line in fileinput.input(openhook=hook):
File
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/fileinput.py",
line 263, in __next__
line = self.readline()
File
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/fileinput.py",
line 363, in readline
self._buffer = self._file.readlines(self._bufsize)
File
"/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/codecs.py",
line 319, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 3:
invalid start byte
Hook was not called, and so we get the UnicodeDecodeError.
Should fileinput attempt to apply the hook code to stdin?
--
messages: 263409
nosy: jmb236
priority: normal
severity: normal
status: open
title: fileinput handling of unicode errors from standard input
type: behavior
versions: Python 3.4
___
Python tracker
<http://bugs.python.org/issue26756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26756] fileinput handling of unicode errors from standard input
Joel Barry added the comment:
I was suggesting that the openhook could somehow be applied to a
*reopening* of sys.stdin. Something like this:
326c326,329
< self._file = sys.stdin
---
> if self._openhook:
> self._file = self._openhook(self._filename,
> self._mode)
> else:
> self._file = sys.stdin
But this won't work because self._filename here is '' which
isn't a real filename. In conjunction with a change to my hook:
def hook(filename, mode):
if filename == '':
return io.TextIOWrapper(sys.stdin.buffer, errors='replace')
return open(filename, mode, errors='replace')
things would work, but this is a bit awkward.
This works for me without changing my hook:
326c326,329
< self._file = sys.stdin
---
> if self._openhook:
> self._file = self._openhook('/dev/stdin', self._mode)
> else:
> self._file = sys.stdin
but I realize that using /dev/stdin is not portable.
The desired outcome is really just to control Unicode behavior from
stdin, not necessary the ability to provide a generic hook. Adding an
'errors' keyword to apply to stdin would solve my case, but if you
open up 'errors', someone may also want 'encoding', and the others,
which is why it would be nicer if this could somehow be solved with
the existing openhook interface.
--
___
Python tracker
<http://bugs.python.org/issue26756>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: I took care of the tarfile module. Added the following according to the first message: tarfile.CompressionError tarfile.HeaderError tarfile.ReadError tarfile.open The following were included in __all__ that were not explicitly mentioned in the first message but were denoted as an exported function, exported class, or an exported error. tarfile.main tarfile.TarIter tarfile.StreamError tarfile.ExtractError tarfile.SubsequentHeaderError tarfile.InvalidHeaderError tarfile.EmptyHeaderError tarfile.EOFHeaderError tarfile.TruncatedHeaderError This is my first patch so feedback is highly appreciated. -- keywords: +patch nosy: +taddeimania Added file: http://bugs.python.org/file39051/Issue23883_tarfile_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Joel Taddei : Removed file: http://bugs.python.org/file39051/Issue23883_tarfile_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: Thanks for the feedback. I was unsure how to proceed with the undocumented items that seemed to be categorized as exported. Thanks for catching ENCODING & *_FORMAT. -- Added file: http://bugs.python.org/file39064/Issue23883_tarfile_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Changes by Joel Taddei : Removed file: http://bugs.python.org/file39064/Issue23883_tarfile_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: Put HeaderError back in and removed the extra XHDTYPE. We can get more input on the type constants as well as the undocumented but exported items. Could just be cleared up with some edits to documentation. -- Added file: http://bugs.python.org/file39065/Issue23883_tarfile_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: I took a stab at the calendar module. Found a few items in the documentation which weren't listed in the above list: LocaleTextCalendar, LocaleHTMLCalendar, and weekheader. I was curious though about week and prweek as month and prmonth are documented and exported should we add week and prweek to the export & docs? -- Added file: http://bugs.python.org/file39067/Issue23883_calendar_all.patch ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Joel Taddei added the comment: Woops just noticed above in the issue someone else picked up the Calendar __all__. I am genuinely sorry I didn't intend to duplicate the effort. -- ___ Python tracker <http://bugs.python.org/issue23883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44846] zipfile: cannot create zip file from files with non-utf8 filenames
New submission from Joel Puig Rubio :
I'm attempting to make a script to create ZIP archives from files which
filenames are encoded in Shift-JIS. However, Python seems to limit its
filenames to ASCII or UTF-8, which means that attempting to archive said files
will raise an exception. This is very inconvenient.
joel@bliss:~/test$ python3 -m zipfile -c mojibake.zip .
Traceback (most recent call last):
File "/usr/lib/python3.8/zipfile.py", line 457, in _encodeFilenameFlags
return self.filename.encode('ascii'), self.flag_bits
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-7:
ordinal not in range(128)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.8/zipfile.py", line 2441, in
main()
File "/usr/lib/python3.8/zipfile.py", line 2437, in main
addToZip(zf, path, zippath)
File "/usr/lib/python3.8/zipfile.py", line 2426, in addToZip
addToZip(zf,
File "/usr/lib/python3.8/zipfile.py", line 2421, in addToZip
zf.write(path, zippath, ZIP_DEFLATED)
File "/usr/lib/python3.8/zipfile.py", line 1775, in write
with open(filename, "rb") as src, self.open(zinfo, 'w') as dest:
File "/usr/lib/python3.8/zipfile.py", line 1517, in open
return self._open_to_write(zinfo, force_zip64=force_zip64)
File "/usr/lib/python3.8/zipfile.py", line 1614, in _open_to_write
self.fp.write(zinfo.FileHeader(zip64))
File "/usr/lib/python3.8/zipfile.py", line 447, in FileHeader
filename, flag_bits = self._encodeFilenameFlags()
File "/usr/lib/python3.8/zipfile.py", line 459, in _encodeFilenameFlags
return self.filename.encode('utf-8'), self.flag_bits | 0x800
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-7:
surrogates not allowed
The zip command from the Linux Info-ZIP package is able to create the same
archive with no issues, which I've attached to this issue. Here you can see how
the proper filenames are shown in WinRAR once the right encoding is selected:
https://i.imgur.com/TVcI95A.png
The same should be seen on any computer using Shift-JIS as their locale.
--
components: Library (Lib)
files: mojibake.zip
messages: 399049
nosy: joelpuig
priority: normal
severity: normal
status: open
title: zipfile: cannot create zip file from files with non-utf8 filenames
versions: Python 3.8
Added file: https://bugs.python.org/file50204/mojibake.zip
___
Python tracker
<https://bugs.python.org/issue44846>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36281] OSError: handle is closed for ProcessPoolExecutor and run_in_executor
Change by Joel Lopes Da Silva : -- nosy: +JoeKun ___ Python tracker <https://bugs.python.org/issue36281> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
