[issue32219] SSLWantWriteError being raised by blocking SSL socket
Change by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <https://bugs.python.org/issue32219> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43061] subprocess: feature request: Get only the stdout of the last shell command
Kyle Altendorf added the comment: I'm not sure why I got added... but as mentioned in the SO response, this isn't how stuff works. Python isn't monitoring what subprocesses are created in the tree below the one Python itself creates nor does it have any way to know which line of which subprocess is creating any given output. -- ___ Python tracker <https://bugs.python.org/issue43061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41836] Improve ctypes error reporting with missing DLL path
Change by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <https://bugs.python.org/issue41836> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25655] Python errors related to failures loading DLL's lack information
Change by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <https://bugs.python.org/issue25655> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38989] pip install selects 32 bit wheels for 64 bit python if vcvarsall.bat amd64_x86 in environment
Change by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <https://bugs.python.org/issue38989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- keywords: +patch pull_requests: +5485 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- pull_requests: +5491 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- pull_requests: +5492 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- pull_requests: +5493 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
Change by Kyle Altendorf : -- pull_requests: +5494 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33617] subprocess.Popen etc do not accept os.PathLike in passed sequence on Windows
New submission from Kyle Altendorf :
PS C:\Users\FSTAB\Desktop\g\20\grid-tied> py -3.6 -c "import os, pathlib,
subprocess; subprocess.run([pathlib.Path()])"
Traceback (most recent call last):
File "", line 1, in
File "C:\Program Files\Python36\lib\subprocess.py", line 403, in run
with Popen(*popenargs, **kwargs) as process:
File "C:\Program Files\Python36\lib\subprocess.py", line 707, in __init__
restore_signals, start_new_session)
File "C:\Program Files\Python36\lib\subprocess.py", line 964, in
_execute_child
args = list2cmdline(args)
File "C:\Program Files\Python36\lib\subprocess.py", line 461, in list2cmdline
needquote = (" " in arg) or ("\t" in arg) or not arg
TypeError: argument of type 'WindowsPath' is not iterable
PR to follow soon.
--
messages: 317408
nosy: altendky
priority: normal
severity: normal
status: open
title: subprocess.Popen etc do not accept os.PathLike in passed sequence on
Windows
___
Python tracker
<https://bugs.python.org/issue33617>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33617] subprocess.Popen etc do not accept os.PathLike in passed sequence on Windows
Change by Kyle Altendorf : -- keywords: +patch pull_requests: +6700 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33617] subprocess.Popen etc do not accept os.PathLike in passed sequence on Windows
Kyle Altendorf added the comment: I totally failed to fill out the metadata, sorry. I would personally consider this more of a bugfix than a feature enhancement, but I don't know how that's decided exactly. It's also quite small. There are a couple other open issues related to full os.PathLike protocol support. -- ___ Python tracker <https://bugs.python.org/issue33617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34606] Unable to read zip file with extra
New submission from Kyle Altendorf :
This was first found over in Twisted tests. We probably aren't too terribly
worried about it but I wanted to report here anyways.
https://twistedmatrix.com/trac/ticket/9525
Both 3.6 and 3.7 write the same file (sha at the end) based on the script in
the first snippet. 3.6 can read both files, 3.7 can't read either.
altendky@lt:~/twisted$ cat ../z.py
import sys
import zipfile
print(sys.version)
fn = sys.argv[1]
print(fn)
with zipfile.ZipFile(fn, 'w') as zf:
zi = zipfile.ZipInfo("0")
zi.extra = b"hello, extra"
zf.writestr(zi, b"the real data")
zipfile.ZipFile(fn)
altendky@lt:~/twisted$ venv36/bin/python ../z.py 36.zip
3.6.6 (default, Jul 24 2018, 16:23:12)
[GCC 6.3.0 20170516]
36.zip
altendky@lt:~/twisted$ venv37/bin/python ../z.py 37.zip
3.7.0 (default, Jul 7 2018, 15:49:24)
[GCC 6.3.0 20170516]
37.zip
Traceback (most recent call last):
File "../z.py", line 14, in
zipfile.ZipFile(fn)
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 1200, in __init__
self._RealGetContents()
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 1323, in _RealGetContents
x._decodeExtra()
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 440, in _decodeExtra
raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)
altendky@lt:~/twisted$ cat ../z.py
import sys
import zipfile
print(sys.version)
fn = sys.argv[1]
print(fn)
#with zipfile.ZipFile(fn, 'w') as zf:
#zi = zipfile.ZipInfo("0")
#zi.extra = b"hello, extra"
#zf.writestr(zi, b"the real data")
zipfile.ZipFile(fn)
altendky@lt:~/twisted$ venv36/bin/python ../z.py 37.zip
3.6.6 (default, Jul 24 2018, 16:23:12)
[GCC 6.3.0 20170516]
37.zip
altendky@lt:~/twisted$ venv37/bin/python ../z.py 36.zip
3.7.0 (default, Jul 7 2018, 15:49:24)
[GCC 6.3.0 20170516]
36.zip
Traceback (most recent call last):
File "../z.py", line 14, in
zipfile.ZipFile(fn)
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 1200, in __init__
self._RealGetContents()
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 1323, in _RealGetContents
x._decodeExtra()
File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py",
line 440, in _decodeExtra
raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)
altendky@lt:~/twisted$ sha256sum 36.zip
0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6 36.zip
altendky@lt:~/twisted$ sha256sum 37.zip
0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6 37.zip
--
components: Library (Lib)
messages: 324743
nosy: altendky
priority: normal
severity: normal
status: open
title: Unable to read zip file with extra
type: crash
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue34606>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34606] Unable to read zip file with extra
Kyle Altendorf added the comment: Turns out the docs do document this. My apologies. https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT 4.3.11 Archive extra data record: archive extra data signature4 bytes (0x08064b50) extra field length 4 bytes extra field data(variable size) Aside from the discrepancy between 16-bits and 4 bytes, it seems like something should happen, even if it's something other than 'fixing' the code to handle the malformed data. Isn't it a bug for zipfile to create a non-compliant file? Shouldn't it either check or provide an interface by which a compliant file could sensibly be created? It doesn't seem great to just expect users to rewrite this each time they call. (42).to_bytes(4, 'little') + len(data).to_bytes(4, 'little') + data or, should it be 'big'? and would it be (len(data) + 4 + 4)? -- ___ Python tracker <https://bugs.python.org/issue34606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34606] Unable to read zip file with extra
Kyle Altendorf added the comment:
Python 3.7 works with 2-byte elements, I managed to find the wrong section in
the doc-linked docs.
4.5 Extensible data fields
--
4.5.1 In order to allow different programs and different types
of information to be stored in the 'extra' field in .ZIP
files, the following structure MUST be used for all
programs storing data in this field:
header1+data1 + header2+data2 . . .
Each header should consist of:
Header ID - 2 bytes
Data Size - 2 bytes
Note: all fields stored in Intel low-byte/high-byte order.
And the test showing it working.
import sys
import zipfile
print(sys.version)
fn = sys.argv[1]
print(fn)
options = {
'endianness': ('little', 'big'),
'header_element_bytes': (2, 4),
'additional_size': (0, 4, 4 + 4),
}
for endianness in options['endianness']:
for additional_size in options['additional_size']:
for header_element_bytes in options['header_element_bytes']:
print('\n\n --- trying endianness: {}, additional_size: {},
header_element_bytes: {}'.format(endianness, additional_size,
header_element_bytes))
with zipfile.ZipFile(fn, 'w') as zf:
zi = zipfile.ZipInfo("0")
extra_data = b"hello, extra, and some more just to make it
longer and such so yeah"
zi.extra = (
(42).to_bytes(header_element_bytes, endianness)
+ (len(extra_data) +
additional_size).to_bytes(header_element_bytes, endianness)
+ extra_data
)
zf.writestr(zi, b"the real data")
try:
zipfile.ZipFile(fn)
except Exception as e:
print(e)
else:
print('success')
altendky@lt:~/twisted$ python3.7 ../z.py 37.py
3.7.0 (default, Jul 7 2018, 15:49:24)
[GCC 6.3.0 20170516]
37.py
--- trying endianness: little, additional_size: 0, header_element_bytes: 2
success
--- trying endianness: little, additional_size: 0, header_element_bytes: 4
Corrupt extra field 6568 (size=27756)
--- trying endianness: little, additional_size: 4, header_element_bytes: 2
Corrupt extra field 002a (size=71)
--- trying endianness: little, additional_size: 4, header_element_bytes: 4
Corrupt extra field 6568 (size=27756)
--- trying endianness: little, additional_size: 8, header_element_bytes: 2
Corrupt extra field 002a (size=75)
--- trying endianness: little, additional_size: 8, header_element_bytes: 4
Corrupt extra field 6568 (size=27756)
--- trying endianness: big, additional_size: 0, header_element_bytes: 2
Corrupt extra field 2a00 (size=17152)
--- trying endianness: big, additional_size: 0, header_element_bytes: 4
Corrupt extra field (size=10752)
--- trying endianness: big, additional_size: 4, header_element_bytes: 2
Corrupt extra field 2a00 (size=18176)
--- trying endianness: big, additional_size: 4, header_element_bytes: 4
Corrupt extra field (size=10752)
--- trying endianness: big, additional_size: 8, header_element_bytes: 2
Corrupt extra field 2a00 (size=19200)
--- trying endianness: big, additional_size: 8, header_element_bytes: 4
Corrupt extra field (size=10752)
--
___
Python tracker
<https://bugs.python.org/issue34606>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34606] Unable to read zip file with extra
Kyle Altendorf added the comment: Vladimir, if compression were the cause wouldn't the extra bytes I added (signature and length) not have any effect? If you've found an issue it seems like it would be a different one than I was triggering. -- ___ Python tracker <https://bugs.python.org/issue34606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29085] Python 3.6 on Windows doesn't seed Random() well enough
Changes by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <http://bugs.python.org/issue29085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29085] Python 3.6 on Windows doesn't seed Random() well enough
Kyle Altendorf added the comment: time.sleep(0) and time.sleep(0.0) acted the same for me and both exhibited matching 'random' values in some cases. (win10, python3.6) I also printed time.time() with each 'random' value and it wasn't a perfect match but matching times tended to go with matching 'random' values. -- ___ Python tracker <http://bugs.python.org/issue29085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29134] contextlib doc bug
Kyle Altendorf added the comment: I would think that the idea of simply adding some reference to `User` such as was suggested with `UserDefinedContextClass` would be reasonable and helpful. This doesn't involve any more code merely a more explanatory name. -- nosy: +altendky ___ Python tracker <http://bugs.python.org/issue29134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27696] win_add2path.py does not add user site directory
New submission from Kyle Altendorf: Since the detected user path has the text `%APPDATA%` replaced into it `os.path.isdir()` returns `False`. As a result, the user site path is not added to the `%PATH%` variable. The patch adds `os.path.expandvars()` to the `isdir()` check to resolve this issue. -- files: win_add2path.patch keywords: patch messages: 272060 nosy: altendky priority: normal severity: normal status: open title: win_add2path.py does not add user site directory type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file44028/win_add2path.patch ___ Python tracker <http://bugs.python.org/issue27696> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28215] PyModule_AddIntConstant() wraps >=2^32 values when long is 4 bytes
New submission from Kyle Altendorf:
I am cross compiling Python 3.5.2 for use on a 32-bit ARM processor with Linux.
I use socket.CAN_EFF_FLAG and noticed that it is negative on the target
despite being positive on my host (64-bit Intel Linux).
Host:
altendky@tp:~$ uname -a
Linux tp 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
altendky@tp:~$ python3 --version
Python 3.5.2
altendky@tp:~$ python3 -c 'import socket; print(socket.CAN_EFF_FLAG)'
2147483648
^^ Is expected
Target:
root@rosi ~$ uname -a
Linux rosi 3.0.101-rt130-opusa3-2.1.0-2 #1 PREEMPT Tue Apr 12 13:49:26 CEST
2016 armv6l GNU/Linux
root@rosi ~$ /opt/epc/bin/python3 --version
Python 3.5.2
root@rosi ~$ /opt/epc/bin/python3 -c 'import socket; print(socket.CAN_EFF_FLAG)'
-2147483648
^^ Is not expected to be negative
Only CAN_EFF_FLAG reference in my source used to cross build Python:
Modules/socketmodule.c:PyModule_AddIntMacro(m, CAN_EFF_FLAG);
Definition in cross compiler include:
altendky@tp:/opt/freescale/usr/local/gcc-4.6.2-glibc-2.13-linaro-multilib-2011.12/fsl-linaro-toolchain/arm-fsl-linux-gnueabi/multi-libs/default/usr/include$
grep -r CAN_EFF_FLAG
linux/can.h:#define CAN_EFF_FLAG 0x8000U /* EFF/SFF is set in the MSB */
For reference, here it is on the host system (looks the same to me):
altendky@tp:/usr/include$ grep -r CAN_EFF_FLAG
linux/can.h:#define CAN_EFF_FLAG 0x8000U /* EFF/SFF is set in the MSB */
But perhaps this `long` type for the value is the issue? If signed and only
4-bytes as is the case on my target then this will misinterpret the 0x8000U
literal resulting in the above observed -2147483648.
PyModule_AddIntConstant(PyObject *m, const char *name, long value)
On my target system, printf("%d", sizeof(long)) yields 4.
For now I just work around it in my application by reassigning it to be it's
absolute value.
socket.CAN_EFF_FLAG = abs(socket.CAN_EFF_FLAG)
--
messages: 277036
nosy: altendky
priority: normal
severity: normal
status: open
title: PyModule_AddIntConstant() wraps >=2^32 values when long is 4 bytes
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28215>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28215] PyModule_AddIntConstant() wraps >=2^31 values when long is 4 bytes
Kyle Altendorf added the comment: I do not seem to be getting a compiler warning. arm-fsl-linux-gnueabi-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes-Werror=declaration-after-statement -I. -IInclude -I./Include -I"/epc/t/262/misc-build-arm-fsl-linux-gnueabi/sysroot/root/all//opt/epc/include" -DPy_BUILD_CORE -c ./Modules/socketmodule.c -o Modules/socketmodule.o To really encompass all cases I think you are correct that both a signed and an unsigned handler are needed. Though, I have an idea for something nifty, I'll share if it works. Regardless, shouldn't they use `intmax_t` and `uintmax_t` from stdtypes.h to make sure they handle anything that could be defined in the referenced C code? In my case simply switching from `long` to `intmax_t` would be sufficient. Note that I am not worried about getting this fixed for my one case. My workaround is fine for my application. I also will hopefully be correcting the subject to >=2**31 if this change does what I think. Good ol' off-by-one. -- title: PyModule_AddIntConstant() wraps >=2^32 values when long is 4 bytes -> PyModule_AddIntConstant() wraps >=2^31 values when long is 4 bytes ___ Python tracker <http://bugs.python.org/issue28215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28215] PyModule_AddIntConstant() wraps >=2^31 values when long is 4 bytes
Kyle Altendorf added the comment: A little macro funny business gets a function the ability to know if the type passed to its wrapping macro is signed or not. http://ideone.com/NZYs7u // http://stackoverflow.com/questions/7469915 #define IS_UNSIGNED(v) (v >= 0 && ~v >= 0) #define F(v) f(IS_UNSIGNED(v), v, v) void f (bool is_unsigned, intmax_t s, uintmax_t u) Looking in `Objects/longobject.c` suggests that perhaps the two functions that could be chosen from would be `PyLong_From[Unsigned]LongLong()` to avoid truncation. Is there some reason not to use these? I don't know the habits of CPython developers to know if there's a significant optimization going on here. Just to throw it out there, in the case of macros, `PyLong_FromString()` might even be usable... Included for quick reference: int PyModule_AddIntConstant(PyObject *m, const char *name, long value) https://hg.python.org/cpython/file/tip/Python/modsupport.c#l566 PyModule_AddIntMacro(m, CAN_EFF_FLAG); https://hg.python.org/cpython/file/tip/Modules/socketmodule.c#l7098 PyObject * PyLong_FromLong(long ival) https://hg.python.org/cpython/file/tip/Objects/longobject.c#l231 #define PyModule_AddIntMacro(m, c) PyModule_AddIntConstant(m, #c, c) https://hg.python.org/cpython/file/tip/Include/modsupport.h#l80 -- ___ Python tracker <http://bugs.python.org/issue28215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26660] tempfile.TemporaryDirectory() cleanup exception on Windows if readonly files created
Changes by Kyle Altendorf : -- nosy: +altendky ___ Python tracker <http://bugs.python.org/issue26660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32852] trace changes sys.argv from list to tuple
New submission from Kyle Altendorf : Normally sys.argv is a list but when using the trace module sys.argv gets changed to a tuple. In my case this caused an issue with running an entry point due to the line: sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) When researching I found: https://stackoverflow.com/questions/47688568/trace-sys-argv-args-typeerror-tuple-object-does-not-support-item-assig They point out where trace assigns a tuple to sys.argv. https://github.com/python/cpython/blob/master/Lib/trace.py#L708 I'll see what I can do to put together a quick patch. $ cat t.py import sys print(sys.version) print(type(sys.argv)) $ /home/altendky/.pyenv/versions/3.7.0a2/bin/python t.py 3.7.0a2 (default, Feb 15 2018, 11:20:36) [GCC 6.3.0 20170516] $ /home/altendky/.pyenv/versions/3.7.0a2/bin/python -m trace --trace t.py --- modulename: t, funcname: t.py(1): import sys t.py(3): print(sys.version) 3.7.0a2 (default, Feb 15 2018, 11:20:36) [GCC 6.3.0 20170516] t.py(5): print(type(sys.argv)) --- modulename: trace, funcname: _unsettrace trace.py(71): sys.settrace(None) -- components: Library (Lib) messages: 312213 nosy: altendky priority: normal severity: normal status: open title: trace changes sys.argv from list to tuple versions: Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue32852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
