[issue29730] unoptimal calls to PyNumber_Check

Serhiy Storchaka added the comment: I think it would be better to replace PyNumber_Check() with PyIndex_Check() and change error messages to more specific. In IO related functions the accepted values are integers and None. In bytes/bytearray methods -- integers and bytes-like objects.

[issue29746] Update marshal docs to Python 3

Changes by Serhiy Storchaka : -- pull_requests: +519 ___ Python tracker ___ ___

[issue29746] Update marshal docs to Python 3

Changes by Serhiy Storchaka : -- pull_requests: +518 ___ Python tracker ___ ___

[issue29798] Handle "git worktree" in "make patchcheck"

Changes by Nick Coghlan : -- pull_requests: +517 ___ Python tracker ___ ___

[issue29656] Change "make patchcheck" to be branch aware

Changes by Nick Coghlan : -- pull_requests: +516 ___ Python tracker ___ ___

[issue29656] Change "make patchcheck" to be branch aware

Nick Coghlan added the comment: http://bugs.python.org/issue29798 is a follow-up issue to make the patchcheck script compatible with `git worktree`. -- ___ Python tracker

[issue29656] Change "make patchcheck" to be branch aware

Changes by Nick Coghlan : -- versions: +Python 3.5 ___ Python tracker ___ ___

[issue29798] Handle "git worktree" in "make patchcheck"

New submission from Nick Coghlan: While backporting issue 29656 to get "make patchcheck" to play nice with git PR branches, I discovered an incompatibility between the way "git worktree" works and the assumptions in "patchcheck.py". Specifically, in a worktree, ".git" is a file, rather than a

[issue29797] Deadlock with multiprocessing.Queue()

Tim Peters added the comment: I think this is expected. Add this as the first line of `simulate()` and the problem should go away: q.cancel_join_thread() As the docs say, a Queue works with a background thread, which feeds incoming data from an internal buffer to a (interprocess) pipe.

[issue29797] Deadlock with multiprocessing.Queue()

New submission from Max: Using multiprocessing.Queue() with several processes writing very fast results in a deadlock both on Windows and UNIX. For example, this code: from multiprocessing import Process, Queue, Manager import time, sys def simulate(q, n_results): for i in

[issue26121] Use C99 functions in math if available

Serhiy Storchaka added the comment: Tests are failed only on s390x RHEL 3.x. http://buildbot.python.org/all/builders/s390x%20RHEL%203.x/builds/446/steps/test/logs/stdio == FAIL: test_mtestfile (test.test_math.MathTests)

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: I am embarrassed! That's why I said IIRC... I remembered that either RichCompare calls RichCompareBool, or the other way around, and I was too lazy to check :) I did remember about do_richcompare, though! On Sat, Mar 11, 2017 at 10:07 PM Tim Peters

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: Elliot, PyObject_RichCompareBool calls PyObject_RichCompare. That in turn does some checks, hides a small mountain of tests in the expansions of the recursion-checking macros, and calls do_richcompare. That in turn does some useless (in the cases you're aiming

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: Eryk Sun: Thanks for your detailed response. I'm curious, though: can you figure out why those other two examples *didn't* fail? It's driving me crazy! For reference: https://bugs.python.org/msg289435 -- ___

[issue29656] Change "make patchcheck" to be branch aware

Changes by Nick Coghlan : -- pull_requests: +515 ___ Python tracker ___ ___

[issue29656] Change "make patchcheck" to be branch aware

Changes by Nick Coghlan : -- pull_requests: +514 ___ Python tracker ___ ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: Ya, that makes sense... I just don't get why it's faster at all, then! Because if we add the (v==w) check, and the tp_richcompare check, how is unsafe_object_compare any different from PyObject_RichComareBool? Is it that we're saving function calls?

[issue29763] test_site failing on AppVeyor

Zachary Ware added the comment: This should be fixed by PR624 and PR625. -- assignee: -> zach.ware components: +Tests stage: -> resolved status: open -> closed type: -> behavior versions: +Python 3.6 ___ Python tracker

[issue29763] test_site failing on AppVeyor

Changes by Zachary Ware : -- resolution: -> fixed ___ Python tracker ___ ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: The impact would be small: it would add one (or so) pointer-equality compare that, in practice, will always say "yup, they're equal". Dirt cheap, and the branch is 100% predictable. -- ___ Python tracker

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: It was a release build -- it would blow up in a debug build. Now, regarding the fix you propose: I'll benchmark it tomorrow. If the impact is small, I agree that it would be an elegant fix. If not, however, perhaps we just have to get rid of

[issue29763] test_site failing on AppVeyor

Changes by Zachary Ware : -- pull_requests: +513 ___ Python tracker ___ ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

Eryk Sun added the comment: > assignment of "__lt__" change the value of the tp_richcompare slot? Yes. CPython doesn't implement individual dispatching of the rich-comparison functions. There's a single tp_richcompare slot, so overriding one rich comparison forces the use of

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: Elliot, did you run the example in a release build or a debug build? I'm wondering why this: assert(v->ob_type == w->ob_type && v->ob_type->tp_richcompare != NULL && v->ob_type->tp_richcompare == compare_funcs.key_richcompare); didn't blow

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: On Sat, Mar 11, 2017 at 9:01 PM Tim Peters wrote: > > Elliot, I don't care if the example behaves differently. Although someone > else may ;-) > > The only things `.sort()` has ever tried to guarantee in the presence of > mutations

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: Elliot, I don't care if the example behaves differently. Although someone else may ;-) The only things `.sort()` has ever tried to guarantee in the presence of mutations (of either the list or the elements) during sorting are that (a) the implementation won't

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: @ppperry, I have no idea what the bulk of the code in typeobect.c is trying to do. -- ___ Python tracker ___

[issue28685] Optimizing list.sort() by performing safety checks in advance

Elliot Gorokhovsky added the comment: I just ran it. With the patched interpreter, I get no error. With the unpatched interpreter, I get ValueError. :(. -- ___ Python tracker

[issue28685] Optimizing list.sort() by performing safety checks in advance

ppperry added the comment: Wouldn't the assignment of "__lt__" change the value of the tp_richcompare slot? That seems to be what the code in Objects/typeobject.c is doing with the update_slot method and the related helper functions. -- ___ Python

[issue29763] test_site failing on AppVeyor

Changes by Zachary Ware : -- pull_requests: +512 ___ Python tracker ___ ___

[issue29794] Incorrect error message on invalid __class__ assignments

Steven D'Aprano added the comment: Your example works because random is a module: py> from types import ModuleType py> import random py> type(random) is ModuleType True Since random is an instance of ModuleType, your class M is a subclass of ModuleType, and assigning to random.__class__ is

[issue28685] Optimizing list.sort() by performing safety checks in advance

Tim Peters added the comment: I haven't tried the example, but at this point I'd be surprised if it failed. The caching here isn't at level of `__lt__` but at the higher level of (invisible from Python code) a type's tp_richcompare slot. A heap type - regardless of whether it derives from a

[issue29796] test_weakref hangs on AppVeyor (2.7)

New submission from Zachary Ware: See PR493 (https://ci.appveyor.com/project/python/cpython/build/2.7.13+.184) for an example. I'd rather not merge PR493, which adds AppVeyor to 2.7, until this is resolved. -- components: Windows messages: 289461 nosy: paul.moore, steve.dower,

[issue29688] Add support for Path.absolute()

Eryk Sun added the comment: What's the rationale for not calling self._flavour.pathmod.abspath() to implement absolute()? For example: >>> p = pathlib.Path('C:/con') >>> p._flavour.pathmod.abspath(p) '.\\con' >>> p._from_parts((p._flavour.pathmod.abspath(p),), init=False)

[issue29795] Clarify how to share multiprocessing primitives

Max added the comment: How about inserting this text somewhere: Note that sharing and synchronization objects (such as `Queue()`, `Pipe()`, `Manager()`, `Lock()`, `Semaphore()`) should be made available to a new process by passing them as arguments to the `target` function invoked by the

[issue28624] Make the `cwd` argument to `subprocess.Popen` accept a `PathLike`

Changes by Zachary Ware : -- pull_requests: +511 ___ Python tracker ___ ___

[issue29730] unoptimal calls to PyNumber_Check

Changes by Oren Milman : -- pull_requests: +510 ___ Python tracker ___ ___ Python-bugs-list

[issue29730] unoptimal calls to PyNumber_Check

Oren Milman added the comment: after some closer examination, ISTM that in Objects/exceptions.c, we can't remove PyNumber_Check to optimize or simplify the code, as the argument 'filename' can be either an integer type (only in case the error is a BlockingIOError), or quite anything else, except

[issue26121] Use C99 functions in math if available

Mark Dickinson added the comment: So the GitHub branch fails on my OS X 10.10 machine: there are a number of test failures for gamma and lgamma (but none for erf and erfc). Some of the gamma and lgamma test failures are accuracy issues; some are more likely to do with errno handling: OS X

[issue29795] Clarify how to share multiprocessing primitives

Davin Potts added the comment: On Windows, because that OS does not support fork, multiprocessing uses spawn to create new processes by default. Note that in Python 3, multiprocessing provides the user with a choice of how to create new processes (i.e. fork, spawn, forkserver). When fork is

[issue29514] Add a test case that prevents magic number changes in minor releases

Eric Appelt added the comment: Thank you for the review and suggestions Nick, Serhiy, and all. I believe that I have implemented the suggestions here and on github into a new commit on my pull request which moves the test into an existing module and removes the notion of a table in favor of a

[issue29795] Clarify how to share multiprocessing primitives

New submission from Max: It seems both me and many other people (judging from SO questions) are confused about whether it's ok to write this: from multiprocessing import Process, Queue q = Queue() def f(): q.put([42, None, 'hello']) def main(): p = Process(target=f) p.start()

[issue29790] Optional use of /dev/random on linux

STINNER Victor added the comment: You can already use os.getrandom() if you want /dev/urandom. And as you wrote, it is easy to inherit from SystemRandom if you need something else than bytes. I am strongly opposed to use /dev/random because most users misunderdood RNG znd so will use

[issue29793] Convert some builtin types constructors to Argument Clinic

Serhiy Storchaka added the comment: str, bytes and bytearray still are not converted. -- ___ Python tracker ___

[issue29688] Add support for Path.absolute()

Changes by Brett Cannon : -- title: Add support for Path.absolute -> Add support for Path.absolute() ___ Python tracker ___

[issue29688] Document Path.absolute

Brett Cannon added the comment: I know it has it's uses (avoiding stat calls is one of them), but it is still undocumented, untested, and has two comments in it saying it needs work. Because of all that it might as well not exist since it doesn't meet our standards of quality. If someone

[issue29688] Add support for Path.absolute

Changes by Brett Cannon : -- title: Document Path.absolute -> Add support for Path.absolute ___ Python tracker ___

[issue29793] Convert some builtin types constructors to Argument Clinic

STINNER Victor added the comment: Cool. You can close my issue, this one supersed it. -- ___ Python tracker ___

[issue29722] heapq.merge docs are misleading with the "reversed" flag

Raymond Hettinger added the comment: The PR was applied to 3.7. I don't think it is worth backing. -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue29794] Incorrect error message on invalid __class__ assignments

Changes by Xiang Zhang : -- nosy: +xiang.zhang ___ Python tracker ___ ___ Python-bugs-list

[issue29794] Incorrect error message on invalid __class__ assignments

New submission from ppperry: If you try to set the __class__ of a type which doesn't support "__class__" assignments, you get the error message: TypeError: __class__ assignment only supported for heap types or ModuleType subclasses However, the actual restriction doesn't require a

[issue28685] Optimizing list.sort() by performing safety checks in advance

ppperry added the comment: What about if one of the relevant comparison functions is implemented in C? class WackyComparator(int): def __lt__(self, other): elem.__class__ = WackyList2 return int.__lt__(self, other)

[issue27200] make doctest in CPython has failures

Changes by Marco Buttu : -- pull_requests: +509 ___ Python tracker ___ ___

[issue29793] Convert some builtin types constructors to Argument Clinic

Changes by Serhiy Storchaka : -- components: +Argument Clinic nosy: +larry stage: -> patch review ___ Python tracker ___

[issue29793] Convert some builtin types constructors to Argument Clinic

Changes by Serhiy Storchaka : -- pull_requests: +508 ___ Python tracker ___ ___

[issue29793] Convert some builtin types constructors to Argument Clinic

New submission from Serhiy Storchaka: Following PR converts some builtin types constructors to Argument Clinic: complex.__new__ float.__new__ function.__new__ int.__new__ mappingproxy.__new__ module.__init__ property.__init__ structseq.__new__ -- components: Interpreter Core messages:

[issue29790] Optional use of /dev/random on linux

Nick Coghlan added the comment: To provide some additional context to that answer: the problem isn't with folks wanting direct access to their hardware entropy devices as such. There are plenty of options for that (such as exposing it as a file descriptor distinct from both /dev/random and

[issue29790] Optional use of /dev/random on linux

Nick Coghlan added the comment: This RFE is unfortunately based on some incorrect assumptions about the way Linux kernels use CSPRNGs and entropy pools. Using /dev/random isn't magically more secure than /dev/urandom, it just makes your applications less reliable for no good reason. Folks

[issue29456] bug in unicodedata.normalize: u1176, u11a7 and u11c3

Changes by Serhiy Storchaka : -- nosy: +lemburg, loewis stage: -> patch review type: -> behavior versions: +Python 3.5, Python 3.7 ___ Python tracker

[issue29456] bug in unicodedata.normalize: u1176, u11a7 and u11c3

Changes by Wonsup Yoon : -- title: bug in unicodedata.normalize: u1176 -> bug in unicodedata.normalize: u1176, u11a7 and u11c3 ___ Python tracker

[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code

Changes by Xiang Zhang : -- resolution: -> duplicate superseder: -> Interpreter aborts when chaining an infinite number of exceptions ___ Python tracker

[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code

David MacIver added the comment: So it does. My apologies. I'll close this. -- stage: -> resolved status: open -> closed ___ Python tracker ___

[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code

Xiang Zhang added the comment: Looks same as #6028. -- nosy: +xiang.zhang ___ Python tracker ___ ___

[issue29792] "Fatal Python error: Cannot recover from stack overflow." from pure Python code

New submission from David MacIver: When run under Python 3.6.0 or 3.5.1 (and presumably other versions of Python 3) the attached code fails with "Fatal Python error: Cannot recover from stack overflow." then aborts with a core dump and an error code indicating it got a SIGABRT. On Python 2.7

[issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files

Serhiy Storchaka added the comment: PR 614: Objects/tupleobject.c -- ___ Python tracker ___ ___

[issue20186] Derby #18: Convert 31 sites to Argument Clinic across 23 files

Changes by Serhiy Storchaka : -- pull_requests: +507 ___ Python tracker ___ ___