[issue26821] array module "minimum size in bytes" table is wrong for int/long

Georg Brandl added the comment: Agreed. -- resolution: -> not a bug status: open -> closed ___ Python tracker ___

[issue26823] Shrink recursive tracebacks

Nick Coghlan added the comment: For testing, you can create a recursive scenario that terminates with an exception after a defined number of iterations: >>> def f(counter): ... if counter: ... f(counter-1) ... else: ... raise RuntimeError ... >>> f(3) Traceback (most

[issue26821] array module "minimum size in bytes" table is wrong for int/long

Serhiy Storchaka added the comment: > I can't get two arrays one int, one byte with the same backing memory where > changes to one effect the other For this case you can use an array or bytearray + memoryview. I think this issue can be closed. -- nosy: +serhiy.storchaka

[issue26821] array module "minimum size in bytes" table is wrong for int/long

Georg Brandl added the comment: Indeed, I don't think the `array` module is much used anymore. If you're looking to serialize or deserialize fixed-size formats, you'll probably want the `struct` module. It has both native and fixed-size modes. For anything else involving arrays (mostly, but

[issue26824] Make some macros use Py_TYPE

Changes by Xiang Zhang : -- type: -> enhancement versions: +Python 3.6 ___ Python tracker ___

[issue26824] Make some macros use Py_TYPE

New submission from Xiang Zhang: According to PEP3123, all accesses to ob_refcnt and ob_type MUST cast the object pointer to PyObject* (unless the pointer is already known to have that type), and SHOULD use the respective accessor macros. I find that there are still some macros in Python use

[issue26823] Shrink recursive tracebacks

Emanuel Barry added the comment: Attached patch also modifies Lib/traceback.py to present identical behaviour, and changes "Previous message" to "Previous line". I'll postpone the more complex implementation of that, and might just not do it as it's indeed better to avoid bugs where we're

[issue26823] Shrink recursive tracebacks

Nick Coghlan added the comment: +1 for the simple approach, and deferring the mutual recursion support - it's desirable to keep traceback printing simple in order to minimise the chance for failures during the display process. In addition to the C implementation of traceback printing, the

[issue22234] urllib.parse.urlparse accepts any falsy value as an url

Changes by Luiz Poleto : -- nosy: +luiz.poleto ___ Python tracker ___ ___

[issue26823] Shrink recursive tracebacks

Emanuel Barry added the comment: The message is mostly a placeholder, but "message" is singular so I figured it would be obvious. But alas, if you are confused, others might be too. Propositions for a better message are welcome :) I'll attempt to make it track chained calls (or mutually

[issue26823] Shrink recursive tracebacks

Xiang Zhang added the comment: With the current patch, a simple test gives the traceback: Traceback (most recent call last): File "", line 1, in File "", line 2, in test File "", line 2, in test File "", line 2, in test [Previous message repeated 995 more times] RecursionError:

[issue26823] Shrink recursive tracebacks

Changes by Ethan Furman : -- nosy: +georg.brandl ___ Python tracker ___ ___

[issue26823] Shrink recursive tracebacks

Ethan Furman added the comment: If you can, give it a go. Make it a new patch, though -- don't delete the existing one. -- ___ Python tracker ___

[issue26823] Shrink recursive tracebacks

Changes by Ethan Furman : -- type: -> behavior ___ Python tracker ___ ___

[issue26823] Shrink recursive tracebacks

Emanuel Barry added the comment: Yes, can't handle mutually recursive functions. I could maybe check for the last two or three functions, but that seems like unnecessary work for something that might not happen as often (I can see it being the case with e.g. __getattr__ though). If enough

[issue26823] Shrink recursive tracebacks

Chris Angelico added the comment: By "doesn't keep track of call chains", you mean that it can't handle mutually-recursive functions, right? Still useful. -- nosy: +Rosuav ___ Python tracker

[issue26823] Shrink recursive tracebacks

Changes by Ethan Furman : -- nosy: +ethan.furman ___ Python tracker ___ ___

[issue26823] Shrink recursive tracebacks

New submission from Emanuel Barry: I recently suggested on Python-ideas ( https://mail.python.org/pipermail/python-ideas/2016-April/039899.html ) to shrink long tracebacks if they were all the same noise (recursive calls). Seeing as the idea had a good reception, I went ahead and implemented

[issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments

Xiang Zhang added the comment: This makes sense. It makes the C version and Python version consistent. -- nosy: +xiang.zhang ___ Python tracker ___

[issue26814] [WIP] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

STINNER Victor added the comment: I created a repository. I will work there and make some experiment. It would help to have a better idea of the concrete performance. When I will have a better view of all requires changes to get best performances everywhere, I will start a discussion to see

[issue26814] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

Changes by STINNER Victor : -- hgrepos: +342 ___ Python tracker ___ ___

[issue26041] Update deprecation messages of platform.dist() and platform.linux_distribution()

Changes by Luiz Poleto : -- nosy: +luiz.poleto ___ Python tracker ___ ___

[issue26820] Prevent uses of format string based PyObject_Call* that do not produce tuple required by docs

Jeremy Kloth added the comment: IMHO, this is a documentation bug with PyObject_CallMethod. The change to its documentation to differ from PyObject_CallFunction was changed back in 2004. It should have been updated then to reflect the already well-entrenched behavior of those 2 (at the

[issue26800] Don't accept bytearray as filenames part 2

STINNER Victor added the comment: bytearray is designed for performance. I don't think that the code creating a filename can be a bottleneck in an application. -- ___ Python tracker

[issue26800] Don't accept bytearray as filenames part 2

Larry Hastings added the comment: I did the path_converter change. IIRC some functions supported bytearray, some did not, and in my quest for consistency I took the superset of functionality and supported bytearray for everything. Sounds to me like bytearray support should be dropped, but

[issue26601] Use new madvise()'s MADV_FREE on the private heap

Julian Taylor added the comment: it defaulted to 128kb ten years ago, its a dynamic threshold since ages. -- ___ Python tracker ___

[issue26601] Use new madvise()'s MADV_FREE on the private heap

Julian Taylor added the comment: ARENA_SIZE is 256kb, the threshold in glibc is up to 32 MB -- ___ Python tracker ___

[issue26601] Use new madvise()'s MADV_FREE on the private heap

David Wilson added the comment: @Julian note that ARENA_SIZE is double the threshold after which at least glibc resorts to calling mmap directly, so using malloc in place of mmap on at least Linux would have zero effect -- nosy: +dw ___ Python

[issue26821] array module "minimum size in bytes" table is wrong for int/long

Jonathan Booth added the comment: Ugly -- if I know I'm dealing with 4-byte data, I can't just specify 'I' or 'L' because it'll be wrong on some platform? Maybe the bug is really the module's design. Seems I need to look elsewhere for other reasons (array seems to want to copy memory, rather

[issue26601] Use new madvise()'s MADV_FREE on the private heap

Julian Taylor added the comment: simplest way to fix this would be to not use malloc instead of mmap in the allocator, then you also get MADV_FREE for free when malloc uses it. The rational for using mmap is kind of weak, the source just says "heap fragmentation". The usual argument for using

[issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments

Josh Rosenberg added the comment: Seems sensible for itemgetter and attrgetter, where all but the first argument is nonsensical anyway. It really seems like methodcaller should allow additional arguments (positional and keyword though), a la functools.partial (the difference being the support

[issue26821] array module "minimum size in bytes" table is wrong for int/long

random832 added the comment: It says *minimum* size for a reason. The *actual* sizes of the types used in array are platform-dependent. 2 is the smallest that an int can be (it is probably not that size on any currently supported platforms, but would have been in DOS), and 4 is the smallest

[issue16679] Add advice about non-ASCII wsgiref PATH_INFO

Graham Dumpleton added the comment: Double back slashes would possibly be an artefact of the some mess that happens when logging out through the Apache error log. -- ___ Python tracker

[issue26822] itemgetter/attrgetter/methodcaller objects ignore keyword arguments

New submission from Serhiy Storchaka: itemgetter(), attrgetter() and methodcaller() objects require one argument. They raise TypeError if less or more than one positional argument is provided. But they totally ignore any keyword arguments. >>> import operator >>> f = operator.itemgetter(1)

[issue26689] Add `has_flag` method to `distutils.CCompiler`

Sylvain Corlay added the comment: Hey, any blocker to getting this in? -- ___ Python tracker ___ ___

[issue26821] array module "minimum size in bytes" table is wrong for int/long

New submission from Jonathan Booth: https://docs.python.org/3.5/library/array.html describes the 'I' and 'i' typecodes as being minimum-size in bytes of 2. The interpreter disagrees: >>> import array >>> a = array.array('i') >>> a.itemsize 4 There is also a bug with the 'L' and 'l' long

[issue26820] Prevent uses of format string based PyObject_Call* that do not produce tuple required by docs

Josh Rosenberg added the comment: The motivation for this change was Mr. STINNER's comment on #26814 ( https://bugs.python.org/issue26814#msg263923 ), where he mentioned the weirdness of PyObject_CallFunction and friends, which complicates the implementation of PyObject_FastCall and alerted

[issue26820] Prevent uses of format string based PyObject_Call* that do not produce tuple required by docs

New submission from Josh Rosenberg: PyObject_CallMethod explicitly documents that "The C arguments are described by a Py_BuildValue() format string that should produce a tuple." While PyObject_CallFunction doesn't document this requirement, it has the same behavior, and the same failures, as

[issue16679] Add advice about non-ASCII wsgiref PATH_INFO

Andrew Clover added the comment: > Why only PATH_INFO is encoded in such a manner, but QUERY_STRING is passed > without any changes and does not requires any latin-1 to utf-8 recodings? Laziness: QUERY_STRING should be pure-ASCII, making any such transcoding a no-op. In principle a user

[issue26819] _ProactorReadPipeTransport pause_reading()/resume_reading() broken if called before any read is perfored

New submission from Fulvio Esposito: Calling pause_reading()/resume_reading() on a _ProactorReadPipeTransport will result in an InvalidStateError('Result is not ready.') from a future if no read has been issued yet. The reason is that resume_reading() will schedule _loop_reading() a second

[issue26814] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

Serhiy Storchaka added the comment: PyObject_Call*() implementations with _PyObject_FastCall() look much more complex than with PyObject_Call() (even not counting additional complex functions in modsupport.c). And I'm not sure there is a benefit. May be for first stage we can do without this.

[issue7275] CoverageResult fails to merge input file with non-empty callers in trace.py

Berker Peksag added the comment: Thanks for the report and for the patch, Christian. Here is a patch with a test. -- nosy: +berker.peksag title: CoverageResult fails to merge input file with non-empty callers in trace.py (patch) -> CoverageResult fails to merge input file with

[issue26814] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

STINNER Victor added the comment: > I believe I got a very simple version of it working at one point, supporting > positional parameters only, with some optional arguments. Yeah, that would be a nice first step. > p.s. My last name has two S's. If you continue to leave off one of them, I >

[issue26814] Add a new _PyObject_FastCall() function which avoids the creation of a tuple or dict for arguments

STINNER Victor added the comment: Since early microbenchmarks are promising, I wrote a more complete implementations which tries to use the fast-path (avoid temporary tuple/dict) in all PyObject_Call*() functions. The next step would be to add a METH_FASTCALL flag. IMHO adding such new flag

[issue26818] trace CLI doesn't respect -s option

New submission from Berker Peksag: I noticed this while triaging issue 9317. Using traceme.py from that issue, $ ./python -m trace -c -s traceme.py returns nothing. It seems like it's a regression caused by https://github.com/python/cpython/commit/17e5da46a733a1a05072a277bc81ffa885f0c204

[issue9317] Incorrect coverage file from trace test_pickle.py

Berker Peksag added the comment: A patch similar to issue9317.2.patch has been applied in 0aa46b9ffba3. However, I noticed a regression and created issue 26818. I can confirm that this issue is fixed with the patch from issue 26818 applied. -- nosy: +berker.peksag resolution: ->

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Larry Hastings added the comment: Yes, I've been working on a patch to do this as well. I called the calling convention METH_RAW, to go alongside METH_ZERO METH_O etc. My calling convention was exactly the same as yours: PyObject *(PyObject *o, PyObject **stack, int na, int nk). I only had

[issue12743] C API marshalling doc contains XXX

Berker Peksag added the comment: Since 4059e871e74e, PyMarshal_ReadLongFromFile and PyMarshal_ReadShortFromFile can return -1 on error. Return values of those functions were already documented in acb4d43955f6. Some of the usages also check return value of PyErr_Occurred():

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Serhiy Storchaka added the comment: With call_stack-2.patch attribute access in namedtuple is only 25% slower than attribute access in ordinary Python object! Definitely this this worth to continue to experiment! But adding new slot to PyTypeObject sets the bar too high. Try to use your

[issue26817] Docs for StringIO should link to io.BytesIO

New submission from Thomas Guettler: I think a warning at the top of StringIO docs is needed. And it should link to io.BytesIO. Maybe even deprecate StringIO and cStringIO in Python2? StringIO docs: https://docs.python.org/2/library/stringio.html io.BytesIO docs:

[issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD 10.0 3.x" buildbot

STINNER Victor added the comment: Another different failure. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/4362/steps/test/logs/stdio == FAIL: test_refcycle (test.test_ssl.BasicSocketTests)

[issue26816] Make concurrent.futures.Executor an abc

Changes by Xiang Zhang : -- type: -> enhancement versions: +Python 3.5, Python 3.6 ___ Python tracker ___

[issue22359] Remove incorrect uses of recursive make

Xavier de Gaye added the comment: _freeze_importlib and pgen are cross-built in this patch. Patch tested with a run of the testsuite after a cross-build. -- Added file: http://bugs.python.org/file42554/crossbuild-sources-readonly_2.patch ___ Python

[issue26816] Make concurrent.futures.Executor an abc

Xiang Zhang added the comment: Update the patch to remove more unnecessary base object. -- Added file: http://bugs.python.org/file42553/make_concurrent_futures_Executor_an_abc_v2.patch ___ Python tracker

[issue26750] Mock autospec does not work with subclasses of property()

Changes by Berker Peksag : -- components: +Library (Lib) -Tests nosy: +berker.peksag stage: -> patch review type: enhancement -> behavior versions: +Python 3.5, Python 3.6 ___ Python tracker

[issue26803] syslog logging handler fails with address in unix abstract namespace

Xavier de Gaye added the comment: In makesockaddr(), the current implementation does not do any decoding of AF_UNIX addresses in the abstract namespace in the struct sockaddr_un to bytes direction, i.e. system to python direction, but does encode a string or bytes object to struct sockaddr_un

[issue26804] Prioritize lowercase proxy variables in urllib.request

Hans-Peter Jansen added the comment: Here's the finalized version of this patch, including unit tests. -- Added file: http://bugs.python.org/file42552/python-urllib-prefer-lowercase-proxies-v4.diff ___ Python tracker

[issue26816] Make concurrent.futures.Executor an abc

New submission from Xiang Zhang: The documentation tells that concurrent.futures.Executor is an abstract class. Also PEP3148 tells so and says concurrent.futures.Executor.submit is an abstract method and must be implemented by Executor subclasses. I think using abc.ABCMeta here is a good

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

STINNER Victor added the comment: call_stack-2.patch: A little bit more complete patch, it adds a tp_call_stack field to PyTypeObject an use it in _PyObject_CallStack(). Updated microbenchmark on Python 3.6, best of 3 runs: ./python -m timeit -r 11 -s "from collections import namedtuple as n;

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Serhiy Storchaka added the comment: See also issue23507. May be your function help to optimize filter(), map(), sorted()? -- ___ Python tracker ___

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

STINNER Victor added the comment: Microbenchmark on Python 3.6, best of 3 runs: ./python -m timeit -r 11 -s "from collections import namedtuple as n; a = n('n', 'a b c')(1, 2, 3)" -- "a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a; a.a" * Python 3.6

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Serhiy Storchaka added the comment: "Stack" in the function name looks a little confusing. I understand that this is related to the stack of bytecode interpreter, but this looks as raising pretty deep implementation detail. The way of packing positional and keyword arguments in the continuous

[issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD 10.0 3.x" buildbot

STINNER Victor added the comment: The test: def test_dealloc_warn(self): ss = ssl.wrap_socket(socket.socket(socket.AF_INET)) r = repr(ss) with self.assertWarns(ResourceWarning) as cm: ss = None support.gc_collect() <~ SIGBUG occurred

[issue26815] SIGBUS in test_ssl.test_dealloc_warn() on "AMD64 FreeBSD 10.0 3.x" buildbot

New submission from STINNER Victor: Oh oh, that's not good. test_ssl crashed in test_dealloc_warn() on the "AMD64 FreeBSD 10.0 3.x" buildbot. http://buildbot.python.org/all/builders/AMD64%20FreeBSD%2010.0%203.x/builds/4348/steps/test/logs/stdio [ 39/400] test_ssl Fatal Python error: Bus error

[issue26811] segfault due to null pointer in tuple

STINNER Victor added the comment: Oh, I see "The property() getter calls are up to 25% faster. (Contributed by Joe Jevnik in issue 23910.)" in https://docs.python.org/dev/whatsnew/3.5.html#optimizations Hum... This is embarrassing :-/ Ok, let's keep it, but we must fix it ;-) --

[issue26811] segfault due to null pointer in tuple

Serhiy Storchaka added the comment: > I suggest to remove the micro-optimization from Python 3.5 for safety. Then we should remove the promise from What's New In Python 3.5. That will cause a regression in namedtuple attributes access about 30%. --

[issue22359] Remove incorrect uses of recursive make

Martin Panter added the comment: For the record, to fix this in 2.7 will involve backporting revision c2a53aa27cad, plus Xavier’s patch (except the freeze_importlib parts which is not relevant to 2.7). -- ___ Python tracker

[issue26799] gdb support fails with "Invalid cast."

STINNER Victor added the comment: Great! -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue26811] segfault due to null pointer in tuple

STINNER Victor added the comment: I created the issue #26814: "Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments". -- ___ Python tracker

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

Changes by STINNER Victor : -- nosy: +yselivanov ___ Python tracker ___ ___

[issue26814] Add a new _PyObject_CallStack() function which avoids the creation of a tuple or dict for arguments

New submission from STINNER Victor: Attached patch adds the following new function: PyObject* _PyObject_CallStack(PyObject *func, PyObject **stack, int na, int nk); where na is the number of positional arguments and nk is

[issue22359] Remove incorrect uses of recursive make

Martin Panter added the comment: I see. I guess it would keep the makefile simpler if we cross-compiled both programs, and never used them. -- ___ Python tracker

[issue26804] Prioritize lowercase proxy variables in urllib.request

Hans-Peter Jansen added the comment: Here we go: v3 fixes following issues: * prefer lowercase proxy environment settings, if multiple (disagreeing) settings are specified with differing case schemes (e.g. HTTP_PROXY vs. http_proxy) * an empty proxy variable value resets the related setting

[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions

Andy Maier added the comment: Just for completeness: The "ld" package is now called "distro" and its v0.6.0 is on PyPI: https://pypi.python.org/pypi/distro -- ___ Python tracker

[issue26811] segfault due to null pointer in tuple

STINNER Victor added the comment: I suggest to remove the micro-optimization from Python 3.5 for safety. I'm ok to experiment a new safer implementation on Python 3.6 ;-) We have more time to fix the code in Python 3.6 if new issues are found. Setting the tuple size to zero looks simple and

[issue26811] segfault due to null pointer in tuple

Serhiy Storchaka added the comment: References: Issue23910 -- added original optimization (661cdbd617b8). Issue24276 -- it was significant rewritten (5dbf3d932a59). My suggestion in msg263886 to revert the optimization was related to the original code. Now, after reminding the background, I

[issue26811] segfault due to null pointer in tuple

STINNER Victor added the comment: > Maybe a new C function can be designed to call a function: it would uses > PyEval_EvalCodeEx() to call functions implemented in Python, or create the > tuple for functions implemented in C. I would expect C code to be more optimized that Python functions,

[issue26811] segfault due to null pointer in tuple

STINNER Victor added the comment: Serhiy: "Ah, yes, 5dbf3d932a59 partially fixed this optimization." Since we already talking about hacks, another hack is to hide this private tuple from the GC using _PyObject_GC_UNTRACK(): see attached property_descr_get_gc_untrack.patch. Note: I dislike my

[issue22359] Remove incorrect uses of recursive make

Xavier de Gaye added the comment: > Why do you make the linking of _freeze_importlib conditional, but always > build $(PGEN)? Yes, this is not consistent. The cross-build is correct when both are linked or when both are not linked. And $(PGENOBJS) are cross-compiled in both cases. Should

[issue26799] gdb support fails with "Invalid cast."

Thomas added the comment: Thank you for the quick integration and fixing the return. I have signed the electronic form yesterday. -- ___ Python tracker

[issue26811] segfault due to null pointer in tuple

Serhiy Storchaka added the comment: Sorry, I'm late with my comments. All my posts are written without seeing your previous message. -- ___ Python tracker

[issue26811] segfault due to null pointer in tuple

Serhiy Storchaka added the comment: Ah, yes, 5dbf3d932a59 partially fixed this optimization. Saving None in a tuple (as I believe done in itertools/zip/enumerate optimization) should fix this issue. I agree that the code is too tricky (as well as the code in itertools/zip/enumerate). It would

[issue26811] segfault due to null pointer in tuple

Raymond Hettinger added the comment: I concur. Please do the honors and revert it from 3.5 and 3.6. -- assignee: rhettinger -> serhiy.storchaka ___ Python tracker

[issue26811] segfault due to null pointer in tuple

Changes by Raymond Hettinger : -- priority: normal -> high ___ Python tracker ___

[issue26811] segfault due to null pointer in tuple

Serhiy Storchaka added the comment: 661cdbd617b8 can cause problems with recursion and with cached getters. I suggest to revert it. -- ___ Python tracker

[issue26811] segfault due to null pointer in tuple

Raymond Hettinger added the comment: Also, see https://hg.python.org/cpython/rev/5dbf3d932a59 Serhiy, I'll thinking the whole optimization ought to be reverted as being too tricky and error-prone for the small benefit. A less aggressive approach would be to have the tuple save a valid object

[issue26813] Wrong Japanese translation of "Adverb" on Documentation

Changes by Benjamin Peterson : -- resolution: -> third party status: open -> closed ___ Python tracker ___

[issue26809] `string` exposes ChainMap from `collections`

Raymond Hettinger added the comment: ChainMap___all___2.patch looks good. I would be fine with this going into 3.5 as well (ChainMap is not part of the documented API for the string module). -- ___ Python tracker

[issue26813] Wrong Japanese translation of "Adverb" on Documentation

INADA Naoki added the comment: Thank you for reporting. Japanese translation team has own issue tracker in Github. I copied this issue to https://github.com/python-doc-ja/python-doc-ja/issues/733 -- nosy: +naoki ___ Python tracker

[issue26809] `string` exposes ChainMap from `collections`

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___

[issue26811] segfault due to null pointer in tuple

Changes by Raymond Hettinger : -- assignee: -> rhettinger nosy: +rhettinger ___ Python tracker ___