[issue36853] inconsistencies in docs builds (Sphinx 2)
David Jones added the comment: I believe the issue is only triggered if you actually have some suspicious markup in your documentation (which is why your plain build on Sphinx 2 appears to work). Remove some lines from Doc/tools/susp-ignored.csv to trigger it. -- nosy: +drj ___ Python tracker <https://bugs.python.org/issue36853> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21748] glob.glob does not sort its results
David Jones added the comment: The original bug report did not mention ls (note serhiy.storchaka). It is a red herring. I accept that the Python community doesn't care to have glob.glob sorted. But then I think you should distance yourself from the shell in the documentation. It currently says: "The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell" You could say something like: "The glob module finds all the pathnames matching a specified pattern, using a syntax inspired by the Unix shell; unlike Unix shell the ordering is not guaranteed" -- ___ Python tracker <http://bugs.python.org/issue21748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25511] multiprocessing pool blocks SIGTERM from being handled
New submission from David Jones: This is probably related to #21913, but more specifically concerns the documentation. I have a sub process of a larger program that handles a SIGTERM sent by the main process for a clean shutdown. However, if I launch a parallel task in the sub process, via multiprocessing.Pool.imap_unordered, all signals are blocked until pool finishes running the task. If this isn't going to be fixed, then it ought to at least be clearly documented. It took a very long time to diagnose this problem. It requires a programmer to understand the underlying implementation of a high-level construct, thus defeating the purpose of using a high level construct. Also, is there a way to work around this? -- assignee: docs@python components: Documentation messages: 253678 nosy: djones, docs@python priority: normal severity: normal status: open title: multiprocessing pool blocks SIGTERM from being handled type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25511> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21748] glob.glob does not sort its results
New submission from David Jones: ``` for f in glob.glob('input/*/*.dat'): print f ``` outputs: ``` input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat ``` Note that these are not in the right order. Compare with shell which always sorts its globs: ``` drj$ printf '%s\n' input/*/*.dat input/ghcnm.v3.2.2.20140506/ghcnm.tavg.v3.2.2.20140506.qca.dat input/ghcnm.v3.2.2.20140611/ghcnm.tavg.v3.2.2.20140611.qca.dat ``` I think the shell behaviour is better and we should be allowed to rely on glob.glob sorting its result. Note from the documentation: "The glob module finds all the pathnames matching a specified pattern according to the rules used by the Unix shell". The Unix shell has always sorted its globs. -- components: Library (Lib) messages: 220441 nosy: drj priority: normal severity: normal status: open title: glob.glob does not sort its results versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue21748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20742] 2to3 zip fixer doesn't fix for loops.
New submission from David Jones: Consider the following code: for z in zip([1]):pass 2to3 does not convert the zip in this code to list(zip(...)); it does not change this code at all. That can be an (obscure) bug because the zip in Python 2 has different semantics from the zip in Python 3. The output of this program from __future__ import print_function S = [] def l(c): for i in [0,1]: S.append(c) yield i S.append(c.upper()) la = l('a') lb = l('b') for a,b in zip(la, lb): S.append("#") print(''.join(S)) is different in Python 2 and Python 3 (when converted with 2to3, which doesn't change the program). In Python 2 the output is: ababA## In Python 3 the output is: ab#ab#A Obviously this example is somewhat contrived, but I have a non-contrived example involving decoding PNG images (if anyone is interested). -- components: 2to3 (2.x to 3.x conversion tool) messages: 211989 nosy: drj priority: normal severity: normal status: open title: 2to3 zip fixer doesn't fix for loops. type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue20742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18987] distutils.utils.get_platform() for 32-bit Python on a 64-bit machine
David Jones added the comment: Has there been any progress made on fixing this? I ran into this trying to install numpy via pip, 32-bit python installation on 64-bit Centos 6.4. It get's the compile flags right, but not the linker: C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status Someone worked around this by changing ccompiler.py, line 693 to: runtime_library_dirs=None, debug=0, extra_preargs=['-m32'], See: http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-version-of-numpy I tried using the setarch command, which alters the output of uname, but it didn't change anything: setarch i686 pip install numpy This changes the output of uname from Linux centos63-vm 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux to Linux centos63-vm 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 18:37:12 UTC 2013 i686 i686 i386 GNU/Linux So if get_platform really depends on uname, then why doesn't this work? -- nosy: +djones ___ Python tracker <http://bugs.python.org/issue18987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6387] floor division gives different result for int versus float.
David Jones added the comment: I do realise that. I still think the mathematically correct answer should be computed, since it can be. -- ___ Python tracker <http://bugs.python.org/issue6387> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6387] floor division gives different result for int versus float.
New submission from David Jones : Consider: x//y != x//float(y) for some integer values of x and y. For example, x = 2**54-1, and y = 2: >>> x=2**54-1 >>> y=2 >>> x//y 9007199254740991L >>> x//float(y) 9007199254740992.0 >>> _==x//y False I have no idea whether this should actually be a bug or not. The behaviour (above) _is_ the documented behaviour (because the operands are documented as being converted to a common type). But... I think there's a good case for computing the mathematically correct answer regardless of the types of the inputs. For one thing, one of the reasons behind introducing the // operator was to make division the same regardless of whether the inputs were floating point or int. Computing the mathematically correct answer (which since the answer is an integer is always exactly representable in Python) would be better, and simpler to document. -- components: Interpreter Core messages: 89915 nosy: drj severity: normal status: open title: floor division gives different result for int versus float. type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue6387> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 12 Feb 2009, at 09:00, David Jones wrote: > > David Jones added the comment: > > The following program does a very basic do-i-get-back-what-i-wrote > test. > sunau can't cope; I am investigating. I see. sunau uses mu-law compression by default which makes it non- invertable. How stupid. Inserting: w.setcomptype('NONE', 'Pointless Argument') just after setframerate fixes the tests so that all 3 modules pass. Of course, this is still only the most very basic test that one might want to do. And it doesn't cover the case mentioned in this bug report anyway. (drat, just found this, should've sent it yesterday) ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: The following program does a very basic do-i-get-back-what-i-wrote test. sunau can't cope; I am investigating. #!/usr/bin/env python # $Id$ # Audio File Tests import aifc import sunau import wave import struct import sys from StringIO import StringIO frames = struct.pack('256B', *range(256)) log = sys.stderr # Basic test of reproducability. # We test that a set of frames (an entirely artifical set, see `frames`, # above) can be written to an audio file and read back again to get the # same set of frames. # We test mono/stereo, 8-bit/16-bit, and a few framerates. # As of 2009-02-12 sunau does not pass these tests, so I recommend that # you remove it. for af in (aifc, sunau, wave): for nchannels in (1, 2): for sampwidth in (1, 2): for framerate in (11000, 44100, 96000): print >> log, "%s %d/%d/%d" % (af.__name__, nchannels, sampwidth, framerate) f = StringIO() w = af.open(f, 'w') w.setnchannels(nchannels) w.setsampwidth(sampwidth) w.setframerate(framerate) w.writeframesraw(frames) w.close() s = f.getvalue() f = StringIO(s) w = af.open(f) assert w.getnchannels() == nchannels assert w.getsampwidth() == sampwidth assert w.getframerate() == framerate assert w.readframes(len(frames)//nchannels//sampwidth) == frames assert w.readframes(1) == '' ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 10 Feb 2009, at 21:15, David Jones wrote: > > David Jones added the comment: > > On 10 Feb 2009, at 16:57, Guilherme Polo wrote: > >> >> Guilherme Polo added the comment: >> >> Now, is there some problem if we remove the calls to the "tell" >> method >> in _write_header ? See patch attached (tests are very welcome too). > > Yes Ahem. Pardon me for answering you without reading your patch. I have now read your patch and it does more than just remove the calls to "tell". In fact it looks very fine. It makes wave.py more like sunau.py in that it "just knows" what the offsets into the header are. I think I like that (especially the way you use the struct format string to compute the second offset). It also removes that nagging question at the back of my mind: "why does wave.py use tell when it could simply just know the offsets, which are constant anyway?". And it works. How cool is that? I had changed my project to use sunau anyway, because that worked with pipes already. Tests, you say... ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 10 Feb 2009, at 16:57, Guilherme Polo wrote: > > Guilherme Polo added the comment: > > Now, is there some problem if we remove the calls to the "tell" method > in _write_header ? See patch attached (tests are very welcome too). Yes ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 10 Feb 2009, at 13:02, David Jones wrote: > > I also note that my patch can be improved by removing its last 11 > lines. Er, no it can't. What was I thinking? ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 10 Feb 2009, at 12:28, Guilherme Polo wrote: > > Guilherme Polo added the comment: > > I'm really unsure about the proposed patch. Perhaps my example was too trivial. The point is that if you call setnframes then you can get wave.py to avoid patching the header; so it does not need to seek on the output file. However, that _still_ doesn't let you pipe the output, because of the "tell" problem. That's what the patch is for. Here is a (slightly) less trivial example: #!/usr/bin/env python import sys import wave w = wave.open(sys.stdout, 'w') w.setnchannels(1) w.setsampwidth(1) w.setframerate(2000) w.setnframes(100) for _ in range(50): w.writeframesraw('\x00\xff') w.close() (The wave file that it outputs is 100ms of 1000 Hz sine wave by the way) Note the call to setnframes _before_ the data is written. That's what means the header does not need to be patched. With my patch applied the output of this program can be fed to a pipe. If you remove the call to setnframes then the header will need to be patched, and this still (correctly, usefully) raises an error with my patch applied. ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: On 10 Feb 2009, at 12:28, Guilherme Polo wrote: > > Guilherme Polo added the comment: > > Wouldn't it be better if you only ignored the 'illegal seek' error > instead of ignoring any ioerror (should it even be always discarded) ? No. > I > get a 'bad file descriptor' under Windows 7, but, again, can it be > always discarded ? Yes. To expand: Observe that the exception is raised when we are writing the header for the first time. The exception is not raised when we attempt to seek to patch the header, it is raised when we recording the file position so that we can seek to it later. We record the file position even though we might not use it later (the file position is only needed if we need to patch the header). So if we don't need to patch the header, we do not need the file position. So we can clearly ignore any error in attempting to get the file position. If we do need to patch the header, then we need the file position. If we do not have the file position (because the earlier attempt to get it failed), then patching the header will fail when it attempts a seek. This seems reasonable to me. > > You can also reproduce the problem without using wave: > >>>> import sys >>>> sys.stdout.tell() That does not reproduce the problem. The problem is not that tell raises an exception, the problem is that tell raises an exception and it is only being used to get some information that may be not needed later. Therefore the exception should be ignored, and a problem should only be raised if it turns out that we did need for information that we couldn't get. > > I'm really unsure about the proposed patch. Noted. I also note that my patch can be improved by removing its last 11 lines. ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
David Jones added the comment: Attached is a patch which is a diff from this version of wave.py : http://svn.python.org/view/*checkout*/python/trunk/Lib/wave.py?rev=54394 -- keywords: +patch Added file: http://bugs.python.org/file13011/wave-20090210.patch ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5202] wave.py cannot write wave files into a shell pipeline
New submission from David Jones : When using the wave module to output wave files, the output file cannot be a Unix pipeline. Example. The following program outputs a (trivial) wave file on stdout: #!/usr/bin/env python import sys import wave w = wave.open(sys.stdout, 'w') w.setnchannels(1) w.setsampwidth(1) w.setframerate(32000) w.setnframes(0) w.close() It can create a wave file like this: $ ./bugex > foo.wav When used in a pipeline we get: $ ./bugex | wc Traceback (most recent call last): File "./bugex", line 9, in w.close() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py ", line 437, in close self._ensure_header_written(0) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py ", line 458, in _ensure_header_written self._write_header(datasize) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/wave.py ", line 465, in _write_header self._form_length_pos = self._file.tell() IOError: [Errno 29] Illegal seek Exception exceptions.IOError: (29, 'Illegal seek') in > ignored 0 1 8 The wave module has almost all it needs to work around this problem. The wave module will only seek the output if it needs to patch the header. If you use setnframes to write the correct number of frames before writing them with writeframesraw then the header will not be patched upon calling close. However... The problem is that the "tell" method is invoked on the output stream (to record where the header is, in the event that we need to patch it); the "tell" method fails with an exception when the output is a pipeline (see example, above). Exceptions from "tell" when writing the header initially (in _write_header) should be ignored. If _patchheader is later invoked it will fail due to lack of pos. -- components: Library (Lib) messages: 81539 nosy: drj severity: normal status: open title: wave.py cannot write wave files into a shell pipeline type: behavior versions: Python 2.5, Python 2.6 ___ Python tracker <http://bugs.python.org/issue5202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4085] 2.5.2 whatsnew document corrupts names, by having broken HTML, at least on the Web.
New submission from David Jones <[EMAIL PROTECTED]>: Consider the web page: http://www.python.org/doc/2.5.2/whatsnew/acks.html (the problem appears throughout the whatsnew document, but that page happens to be short and have more than one instance). On my browser, Safari 3.1.2 on Intel OS X 10.4.11, Martin von Löwis has his name corrupted, as does Lars Gustäbel. The problem seems to be because whilst the page is encoded in utf-8 the web server does not transmit a Content-Type header that specifies utf-8: $ curl -I http://www.python.org/doc/2.5.2/whatsnew/acks.html HTTP/1.1 200 OK Date: Thu, 09 Oct 2008 08:51:22 GMT Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 mod_ssl/2.2.3 OpenSSL/0.9.8c mod_wsgi/2.0 Python/2.4.4 Last-Modified: Fri, 22 Feb 2008 12:58:18 GMT ETag: "12c008-1336-c6b00e80" Accept-Ranges: bytes Content-Length: 4918 Content-Type: text/html Shouldn't that be "Content-Type: text/html; charset=UTF-8"? Yeah, probably. Shouldn't the browser be using the meta tag in the HTML file itself? Probably, but your broken HTML is preventing Safari from parsing the tag correctly. Specifically: $ curl http://www.python.org/doc/2.5.2/whatsnew/acks.html | grep rel=.first. The title attribute of that link element is incorrect. It features a single-quote inside a single-quoted string. Oopsie. I don't think Safari should be so mean, but bad HTML is bad HTML. Taking a local copy and fixing that title attribute (by using double quotes for example) causes the page to render just fine. -- assignee: georg.brandl components: Documentation messages: 74560 nosy: drj, georg.brandl severity: normal status: open title: 2.5.2 whatsnew document corrupts names, by having broken HTML, at least on the Web. type: behavior versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4085> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4026] fcntl extension fails to build on AIX 6.1
New submission from David Jones <[EMAIL PROTECTED]>: After hacking the configure script to work around the issues http://bugs.python.org/issue4025 and http://bugs.python.org/issue1633863 the build still fails: building 'fcntl' extension xlc_r -DNDEBUG -O -I. -I/home/u0006584/Python-2.6/./Include -I. - IInclude -I./Include -I/home/u0006584/Python-2.6/Include - I/home/u0006584/Python-2.6 -c /home/u0006584/Python- 2.6/Modules/fcntlmodule.c -o build/temp.aix-6.1- 2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o ./Modules/ld_so_aix xlc_r -bI:Modules/python.exp build/temp.aix-6.1- 2.6/home/u0006584/Python-2.6/Modules/fcntlmodule.o -o build/lib.aix-6.1- 2.6/fcntl.so ld: 0711-317 ERROR: Undefined symbol: .flock ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. *** WARNING: renaming "fcntl" since importing it failed:0509-022 Cannot load module build/lib.aix-6.1-2.6. 0509-026 System error: A file or directory in the path name does not exist. error: No such file or directory make: 1254-004 The error code from the last command is 1. (Full transcript attached) I'm mystified and I can't log in to the AIX box right now. This does not appear to be the same as http://bugs.python.org/issue1756343 and http://bugs.python.org/issue1694442 which both appear to be the same, but documenting a differen AIX build problem. -- files: py26aix61script2 messages: 74231 nosy: drj severity: normal status: open title: fcntl extension fails to build on AIX 6.1 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11688/py26aix61script2 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633863] AIX: configure ignores $CC
David Jones <[EMAIL PROTECTED]> added the comment: This is still a problem for Python 2.6 on AIX 6.1. The simplest fix is to change «CC=cc_r» to «CC=${CC:-xlc_r}» but I have no idea how to go about changing the configure script. -- nosy: +drj versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1633863> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4025] C99 comments in Python 2.6 break build on AIX 6.1
New submission from David Jones <[EMAIL PROTECTED]>: Doing a plan "configure" then "make"; the compilation breaks due to // style comments in a file called Objects/frameobject.c: cc_r -qlanglvl=extc89 -c -DNDEBUG -O -I. -IInclude -I./Include - DPy_BUILD_CORE -o Objects/frameobject.o Objects/frameobject.c "Objects/frameobject.c", line 520.9: 1506-046 (S) Syntax error. Full transcript attached. Furthermore, attempting to select a more permissive (better?) compiler, with "CC=c99 ./configure --without-gcc" for example, doesn't work because of the bug reported in http://bugs.python.org/issue1633863 (CC is ignored). I will comment separately in that issue. It is my understanding (per my blog article http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/ ) that the code is now c89 clean (or at least as clean as «gcc -std=c89 - Werror» can make it. That means you should be able to close this bug fairly quickly. :) After I've hacked the configure script the build still fails, but for different reasons. I'll file another bug for that. -- components: Interpreter Core files: py26aix61script1 messages: 74229 nosy: drj severity: normal status: open title: C99 comments in Python 2.6 break build on AIX 6.1 type: compile error versions: Python 2.6 Added file: http://bugs.python.org/file11687/py26aix61script1 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4025> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3166] Make conversions from long to float correctly rounded.
David Jones <[EMAIL PROTECTED]> added the comment: I agree, longs should be correctly rounded when coerced to floats. There is an ugly (but amusing) workaround while people wait for this patch: Go via a string: int(float(repr(295147905179352891391)[:-1])) Though I assume this relies on the platform's strtod working correctly. Which it does for me. -- nosy: +drj ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3166> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com