[issue33056] LEaking files in concurrent.futures.process

Antoine Pitrou <pit...@free.fr> added the comment: Andrew: where there are multiprocessing issues, could you please nosy me so that I get a chance to review? Thomas: thanks for spotting this and thanks for the fix! -- resolution: -> fixed stage: patch review -> resolved

[issue33056] LEaking files in concurrent.futures.process

Antoine Pitrou <pit...@free.fr> added the comment: New changeset f216cbf9ab704da98146a25d57ff0e85aecb49da by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-33056 FIX leaking fd in concurrent.futures.ProcessPoolExecutor (GH-6084) (#6092) https://github.com/python/cpython/

[issue33023] Unable to copy ssl.SSLContext

Antoine Pitrou <pit...@free.fr> added the comment: You won't have any session resumption tickets until a connection succeeds. And even then, I don't think it would be a problem. By design, SSL contexts are meant to be re-used accross multiple conne

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 019f5b3e9e4c2a1297580483c3d5a5a10bddb93b by Antoine Pitrou (Antoine Pietri) in branch 'master': bpo-22674: fix test_strsignal on OSX (GH-6085) https://github.com/python/cpython/commit/019f5b3e9e4c2a1297580483c3d5a5a10b

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Antoine Pitrou <pit...@free.fr> added the comment: > Should I submit a new PR for this? Please do. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Antoine Pitrou <pit...@free.fr> added the comment: Ned, this is why I'd like issue33048 to be solved :-) Having to rely on the buildbot fleet for bugfix iteration is not convenient at all. -- ___ Python tracker <rep...@bugs.python.or

[issue32608] Incompatibilities with the socketserver and multiprocessing packages

Antoine Pitrou <pit...@free.fr> added the comment: Hi Michael, sorry for the silence on this issue. I think the ProcessingMixIn feature is a good idea, I'll give the PR a review when I get the time. -- versions: -Python 2.7, Python 3.4, Python 3.5, Python 3.6, Pyth

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Antoine Pitrou <pit...@free.fr> added the comment: This is now pushed. Thank you Antoine! -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue22674] RFE: Add signal.strsignal(): string describing a signal

Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.8 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32719] fatal error raised when Ctrl-C print loop

Antoine Pitrou <pit...@free.fr> added the comment: Yes, I don't think this can be fixed in an easy way. Let's say that users will have to live with that. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Pyth

[issue33021] Some fstat() calls do not release the GIL, possibly hanging all threads

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 4484f9dca9149da135bbae035f10a50d20d1cbbb by Antoine Pitrou (Nir Soffer) in branch 'master': bpo-33021: Release the GIL during fstat() calls (GH-6019) https://github.com/python/cpython/

[issue33052] Sporadic segmentation fault in test_datetime

New submission from Antoine Pitrou <pit...@free.fr>: Just spotted this in a Travis-CI job: https://travis-ci.org/python/cpython/jobs/351010039#L2002 I'm not sure there's anything to do but I figured it was worth reporting anyway. -- components: Library (Lib), Tests messages:

[issue33023] Unable to copy ssl.SSLContext

Change by Antoine Pitrou <pit...@free.fr>: -- type: crash -> behavior ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33023> ___ __

[issue33023] Unable to copy ssl.SSLContext

Antoine Pitrou <pit...@free.fr> added the comment: > Each connection attempt will require a fresh unadulterated clone of the > ssl.SSLContext instance provided by user to avoid any side-effects from prior > connection attempts. What would those side-effects be? -

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: This is all fixed in the Python 3 branches now. I won't bother with Python 2 as it has quite a different code structure and backporting would take too much of my time. Pox TheGreat, thanks for reporting and the initial

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 069b8d20be8018fbd49ed5aaf64c4caba311e48f by Antoine Pitrou in branch '3.6': [3.6] bpo-31804: Fix multiprocessing.Process with broken standard streams (GH-6079) (GH-6081) https://github.com/python/cpython/

[issue33048] macOS job broken on Travis CI

Antoine Pitrou <pit...@free.fr> added the comment: I meant that the Travis macOS configuration could indeed be maintained by macOS experts, indeed. The alternative, IMHO, would be to declare that bugs in macOS can appear without the offending PR being reverted if it was submitted by

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: New changeset ff5d21331ec6cefec6ba5b78d256d8dbcd67a069 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-31804: Fix multiprocessing.Process with broken standard streams (GH-6079) (GH-6080) https://github.com/python/cpython/

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Change by Antoine Pitrou <pit...@free.fr>: -- versions: +Python 3.8 -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Change by Antoine Pitrou <pit...@free.fr>: -- pull_requests: +5842 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31804> ___ _

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: New changeset e756f66c83786ee82f5f7d45931ae50a6931dd7f by Antoine Pitrou in branch 'master': bpo-31804: Fix multiprocessing.Process with broken standard streams (#6079) https://github.com/python/cpython/

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Change by Antoine Pitrou <pit...@free.fr>: -- superseder: multiprocessing.Process depends on sys.stdout being open -> ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue33048] macOS job broken on Travis CI

New submission from Antoine Pitrou <pit...@free.fr>: Well, it didn't take long. The macOS job broke on Travis CI. Apparently "brew" thinks Python 2 and Python 3 are the same thing, so "brew install python3" now fails with an error message telling to use "bre

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Change by Antoine Pitrou <pit...@free.fr>: -- pull_requests: +5840 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31804> ___ _

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

Antoine Pitrou <pit...@free.fr> added the comment: Perhaps the gemato issue has nothing to do with multiprocessing indeed. I would suggest add some progress logging to your program to see whether/where it actually hangs. -- ___ Python tracke

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

Antoine Pitrou <pit...@free.fr> added the comment: Michał, sorry, I doubt it. The fix is highly non-trivial as it first requires backporting a new feature (see issue14976). I'm cc'ing the 3.6 branch release manager just in case. If apparently you're witnessing this in controlled situ

[issue33019] Review usage of environment variables in the stdlib

Antoine Pitrou <pit...@free.fr> added the comment: I may be mistaken, what's the use of -E if not for security? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32986] multiprocessing, default assumption of Pool size unhelpful

Antoine Pitrou <pit...@free.fr> added the comment: > So this seems like a reasonable heuristic approach to me. You mean duplicating "nproc"'s logic in Python? If someone wants to do the grunt work of implementing/testing it... There's also the question of how that aff

[issue33019] Review usage of environment variables in the stdlib

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +benjamin.peterson ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33019> ___

[issue33019] Review usage of environment variables in the stdlib

New submission from Antoine Pitrou <pit...@free.fr>: Python supports a mode where the interpreter ignores environment variables such as PYTHONPATH, etc. However, there are places in the stdlib where environment-sensitive decisions are made, without regard for the ignore-environmen

[issue32986] multiprocessing, default assumption of Pool size unhelpful

Antoine Pitrou <pit...@free.fr> added the comment: Note that to avoid any kind of environment variable-driven Denial of Service, we should probably ignore NCPUS when sys.flags.ignore_environment is set. -- ___ Python tracker <rep...@bugs.p

[issue32986] multiprocessing, default assumption of Pool size unhelpful

Antoine Pitrou <pit...@free.fr> added the comment: I don't think we want to hardcode special cases for each resource-limiting framework out there: some people care about Docker, others about cgroups, CPU affinity settings, etc. NCPUS has the nice property that each of those framewor

[issue32986] multiprocessing, default assumption of Pool size unhelpful

Change by Antoine Pitrou <pit...@free.fr>: -- type: behavior -> enhancement versions: -Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32986] multiprocessing, default assumption of Pool size unhelpful

Antoine Pitrou <pit...@free.fr> added the comment: Matt, what do you think about this proposal? Is NCPUS the right thing to look at? -- nosy: +Matthew Rocklin type: -> behavior versions: +Python 3.7, Python 3.8 ___ Python tra

[issue32388] Remove cross-version binary compatibility

Antoine Pitrou <pit...@free.fr> added the comment: Yes, let's retarget to 3.8. -- versions: +Python 3.8 -Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32937] Multiprocessing worker functions not terminating with a large number of processes and a manager

Antoine Pitrou <pit...@free.fr> added the comment: I don't know, maybe someone with a Mac wants to try and debug it? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31355] Remove Travis CI macOS job: rely on buildbots

Change by Antoine Pitrou <pit...@free.fr>: -- stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.

[issue31355] Remove Travis CI macOS job: rely on buildbots

Antoine Pitrou <pit...@free.fr> added the comment: New changeset d7687eb4b66c9f675b112eff1169326a1766c111 by Antoine Pitrou in branch 'master': bpo-31355: Travis-CI: re-enable macOS job (#5858) https://github.com/python/cpython/commit/d7687eb4b66c9f675b112eff1169326a17

[issue31355] Remove Travis CI macOS job: rely on buildbots

Antoine Pitrou <pit...@free.fr> added the comment: Last macOS job took 13 minutes and there was almost no wait. That looks ok. I'm not sure it's required to backport to 3.6 and 2.7 since those branches typically have less churn. -- ___

[issue32941] mmap should expose madvise()

Antoine Pitrou <pit...@free.fr> added the comment: For information: - macOS manpage for madvise(): http://www.manpages.info/macosx/madvise.2.html - FreeBSD manpage for madvise(): https://www.freebsd.org/cgi/man.cgi?query=madvise=2 -- ___

[issue32941] mmap should expose madvise()

New submission from Antoine Pitrou <pit...@free.fr>: On POSIX, mmap objects could expose a method wrapping the madvise() library call. I suggest the following API mmap_object.madvise(option[, start[, length]]) If omitted, *start* and *length* would span the whole memory area des

[issue31355] Remove Travis CI macOS job: rely on buildbots

Change by Antoine Pitrou <pit...@free.fr>: -- keywords: +patch pull_requests: +5633 stage: resolved -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32937] Multiprocessing worker functions not terminating with a large number of processes and a manager

Antoine Pitrou <pit...@free.fr> added the comment: I'm not sure... I cannot reproduce your problem on Linux, even with 50 processes and 1 iterations, on Python 3.6.4. Which exact version are you using? What happens if you replace the manager Queue with a non-manager

[issue32937] Multiprocessing worker functions not terminating with a large number of processes and a manager

Antoine Pitrou <pit...@free.fr> added the comment: What happens if you add another process that calls get() on the queue? You should not try to put data on a queue if you don't ever plan to consume it, as the queue's background thread will eventually block until something gets co

[issue31355] Remove Travis CI macOS job: rely on buildbots

Antoine Pitrou <pit...@free.fr> added the comment: The situation with macOS builds on Travis-CI is now much better (no more long waiting queues) so we might revisit this decision. -- status: closed -> pending ___ Python tra

[issue32759] multiprocessing.Array do not release shared memory

Change by Antoine Pitrou <pit...@free.fr>: -- keywords: +patch pull_requests: +5605 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32759] multiprocessing.Array do not release shared memory

Antoine Pitrou <pit...@free.fr> added the comment: It is also possible to uncommit the memory without deallocating it, making reuse potentially faster, but that requires low-level platform-specific code (e.g. madvise(MADV_DONTNEED) on Linux or DiscardVirtualMemory() on W

[issue32759] multiprocessing.Array do not release shared memory

Antoine Pitrou <pit...@free.fr> added the comment: Ok, this is because the multiprocessing Heap object never releases any unused arena objects, so the shared memory you allocate will probably stay allocated until the process tree ends. It is possible to change the strategy to delete

[issue32017] profile.Profile() has no method enable()

Antoine Pitrou <pit...@free.fr> added the comment: We can't remove public-looking methods (i.e. they don't start with an underscore) like that because some people may be using them. Rather than document the differences, I think it would be more useful to try to bridge the gap by augm

[issue32616] Significant performance problems with Python 2.7 built with clang 3.x or 4.x

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32616> ___ __

[issue32616] Significant performance problems with Python 2.7 built with clang 3.x or 4.x

Antoine Pitrou <pit...@free.fr> added the comment: This should remain everyone that backporting performance improvements is not a no-brainer. -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31356] Add context manager to temporarily disable GC

Antoine Pitrou <pit...@free.fr> added the comment: Indeed if unit testing is the main use case, I don't really see the point of adding C code. People can code a simple helper using `contextlib.contextmanager` in a couple of lines. -- ___

[issue32661] ProactorEventLoop locks up on close call

Change by Antoine Pitrou <pit...@free.fr>: -- versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32661> ___ _

[issue32228] truncate() changes current stream position

Antoine Pitrou <pit...@free.fr> added the comment: I've now pushed Nitish's fix to 3.7 and 3.6. I have no interest in backporting to 2.7 at this point. Closing! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7 -Pyt

[issue32228] truncate() changes current stream position

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 1d896ed2cddada4455f40782e4120249defbfa70 by Antoine Pitrou in branch '3.6': [3.6] bpo-32228: Reset raw_pos after unwinding the raw stream (GH-4858) (#5389) https://github.com/python/cpython/

[issue32228] truncate() changes current stream position

Change by Antoine Pitrou <pit...@free.fr>: -- pull_requests: +5224 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32228> ___ _

[issue32228] truncate() changes current stream position

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 059f58ce938d9c3f0286412a4efb1b9131339421 by Antoine Pitrou (Nitish Chandra) in branch 'master': bpo-32228: Reset raw_pos after unwinding the raw stream (#4858) https://github.com/python/cpython/

[issue32430] Simplify Modules/Setup{,.dist,.local}

Antoine Pitrou <pit...@free.fr> added the comment: Le 20/01/2018 à 14:22, STINNER Victor a écrit : > > I don't see how adding an option to make one path configurable would make the > build process more complicated. Do you think implementing and maintaing an option has no co

[issue32430] Simplify Modules/Setup{,.dist,.local}

Antoine Pitrou <pit...@free.fr> added the comment: > Why not adding an option in Makefile or configure to allow to specify a > different path to a custom Setup file? Because we don't want to maintain more config options? Really, I don't to want to further complicate our b

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

Antoine Pitrou <pit...@free.fr> added the comment: New changeset ab74504346a6e2569b3255b7b621c589716888c4 by Antoine Pitrou in branch 'master': bpo-32576: use queue.SimpleQueue in critical places (#5216) https://github.com/python/cpython/commit/ab74504346a6e2569b3255b7b621c58971

[issue21009] Potential deadlock in concurrent futures when garbage collection occurs during Queue.get

Antoine Pitrou <pit...@free.fr> added the comment: There's a proposed fix in https://github.com/python/cpython/pull/5216 It would be nice if someone able to reproduce this issue could test it (the reproducer script here wouldn't work with the new SimpleQueue implemen

[issue32576] concurrent.futures.thread deadlock due to Queue in weakref callback

Antoine Pitrou <pit...@free.fr> added the comment: Thanks for the heads up Mark. Unfortunately the reproducer script https://bugs.python.org/issue21009 needs to hack into Queue.get(), which isn't possible for the C-implemented Simpl

[issue32534] Speed-up list.insert: use memmove()

Antoine Pitrou <pit...@free.fr> added the comment: Le 17/01/2018 à 14:36, Jeethu Rao a écrit : > > On the other hand, on the pyperformance comparison I'd posted yesterday[1], > there seems to be an average improvement of 1.27x on the first seven > benchmarks, and the slowes

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

Change by Antoine Pitrou <pit...@free.fr>: -- keywords: +patch pull_requests: +5069 stage: needs patch -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.pyt

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

Antoine Pitrou <pit...@free.fr> added the comment: We could also switch multiprocessing.Pool. Unfortunately some code in multiprocessing.Pool relies on internal details of queue.Queue (!). -- ___ Python tracker <rep...@bugs.python.or

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou <pit...@free.fr> added the comment: Could you open a new issue for it? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32534] Speed-up list.insert: use memmove()

Antoine Pitrou <pit...@free.fr> added the comment: Ok, I ran the benchmarks here (Ubuntu 16.04, Core i5-2500K, PGO and LTO disabled) and I don't get any consistent speedup, which is more in line with what I was expecting: https://gist.github.com/pitrou/29eb7592fa1eae2be390f3bfa3

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou <pit...@free.fr> added the comment: > Do you think we can deprecate the existing broken non-blocking mode? I would suggest asking on python-dev. I wouldn't mind it, but perhaps there are people using it. -- ___ Python tra

[issue32534] Speed-up list.insert

Antoine Pitrou <pit...@free.fr> added the comment: Thanks. That's really surprising. I'll give it a try myself. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue11849] glibc allocator doesn't release all free()ed memory

Antoine Pitrou <pit...@free.fr> added the comment: Well, memory fragmentation can happen with any allocation scheme, and it's possible even Python 3 isn't immune to this. Backporting performance improvements is a strain on our resources and also constitutes a maintenance threat

[issue11849] glibc allocator doesn't release all free()ed memory

Antoine Pitrou <pit...@free.fr> added the comment: It's not really a fix, it's an improvement, and as such doesn't belong in 2.7. Using malloc() and free() is not a bug in itself. -- ___ Python tracker <rep...@bugs.python.or

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou <pit...@free.fr> added the comment: > And all the async file IO APIs I know [1][2][3] have the public API of "just > like regular files, but the blocking methods are async". 99% of the time, > that means TextWrapper and BufferedStream. So I just

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou <pit...@free.fr> added the comment: Simplifying "with"-related opcodes (and perhaps "finally" ones) sounds nice. "try" blocks are already zero-overhead for practical purposes (i.e. I don't think I've met any workload where moving a

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou <pit...@free.fr> added the comment: Apparently PR 5006 has a conflict. Otherwise, is it ready for review? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32561] Add API to io objects for non-blocking reads/writes

Antoine Pitrou <pit...@free.fr> added the comment: > Ideally we would be able to do buffer-only reads through all the of the > different read methods (read, readline, readinto, ...), Hmm... We already have non-blocking support in BufferedIOReader, except it *doesn't work*.

[issue31368] Support asynchronous, non-blocking buffered reads (RWF_NONBLOCK)

Antoine Pitrou <pit...@free.fr> added the comment: In any case, I think this would take the form of new low-level calls in the posix module, i.e. add thin wrappers around the new system / libc calls. -- nosy: +njs, pitrou ___ Python tracke

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou <pit...@free.fr> added the comment: Ok, there has been enough reviews in the last four months :-) This is now merged. -- resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Pyth

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou <pit...@free.fr> added the comment: New changeset 94e1696d04c65e19ea52e5c8664079c9d9aa0e54 by Antoine Pitrou in branch 'master': bpo-14976: Reentrant simple queue (#3346) https://github.com/python/cpython/commit/94e1696d04c65e19ea52e5c8664079c9d9

[issue32534] Speed-up list.insert

Antoine Pitrou <pit...@free.fr> added the comment: Perhaps the patch is interfering weirdly with PGO? > Should I run the benchmark without a PGO build (i.e without > --enable-optimizations)? That would help clear things up, IMHO. -- __

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Antoine Pitrou <pit...@free.fr> added the comment: Hi all, The PR has been ready for quite some time now. Raymond posted some review comments back in September, which I addressed by making the requested changes. If someone wants to add their comments, now is the time. Otherwise

[issue32346] Speed up slot lookup for class creation

Change by Antoine Pitrou <pit...@free.fr>: -- status: pending -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32346> ___ _

[issue32534] Speed-up list.insert

Antoine Pitrou <pit...@free.fr> added the comment: I'm quite surprised so many benchmarks would be speeded up so significantly by a list.insert() optimization (why a 27% speedup on computing digits of pi, or a 33% speedup on a N-body simulation?). Are you sure the two execu

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

Antoine Pitrou <pit...@free.fr> added the comment: Is nohup required in the example you just posted or is that a red herring? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32516] Add a shared library mechanism for win32

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue32516] Add a shared library mechanism for win32

Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +Ray Donnelly ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32516> ___ _

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou <pit...@free.fr> added the comment: > Thus, as the _pid argument is None in the new process, it launches a new > tracker if it needs to create a new Semaphore I see. Is it an optimization problem, or does it risk leaking semaphores? The problem is if a sema

[issue32346] Speed up slot lookup for class creation

Antoine Pitrou <pit...@free.fr> added the comment: I think that Inada is right: there's too much impact on memory consumption and garbage collection to call this an optimization. Serhiy suggested removing the cache. But, once you remove the cache, you're going to iterate on all values

[issue31310] semaphore tracker isn't protected against crashes

Antoine Pitrou <pit...@free.fr> added the comment: > With this fix, the semaphore_tracker is not shared with the children anymore > and each process launches its own tracker. That's only if the semaphore tracker process cr

[issue32346] Speed up slot lookup for class creation

Antoine Pitrou <pit...@free.fr> added the comment: > Since benchgcclasses.py doesn't creates dunder methods, cache doesn't have GC-tracked tuples, and ref cycles. Hmm, you're right, thank you. I can also reproduce your numbers here (using benchgcclasses2.py). There's definitely

[issue32346] Speed up slot lookup for class creation

Antoine Pitrou <pit...@free.fr> added the comment: Serhiy: > The relative speed up looks nice. But it is just few microseconds per class. > You have to create many thousands of classes to gain a significant fraction > of second. This work started with your message in https://

[issue32346] Speed up slot lookup for class creation

Antoine Pitrou <pit...@free.fr> added the comment: Here is a simple script creating 1 classes (a large number, but perhaps not out of sight for a large application importing a lot of libraries (*)). (*) see the experiment I did in https://mail.python.org/pipermail/python-dev/2017-De

[issue32346] Speed up slot lookup for class creation

Antoine Pitrou <pit...@free.fr> added the comment: Le 11/01/2018 à 20:25, Serhiy Storchaka a écrit : > > I'm not sure how this caching works when change the parent class after > creating the child class. The caching is invalidated at the same place the method cache is invalida

[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.

Antoine Pitrou <pit...@free.fr> added the comment: Please let's stick with PR 5006. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: I'm not using Windows, so I'm unable to test using pythonw. You'll have to provide a fix, or someone else will have to. -- ___ Python tracker <rep...@bugs.python.org> <https://

[issue32493] UUID Module - FreeBSD build failure

Antoine Pitrou <pit...@free.fr> added the comment: Thank you for the fix David! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bu

[issue32493] UUID Module - FreeBSD build failure

Antoine Pitrou <pit...@free.fr> added the comment: New changeset b4ebaa7099c3413b42a9581c4ca560fe7540 by Antoine Pitrou (David Carlier) in branch 'master': bpo-32493: Not only AIX, but FreeBSD has uuid_create support (#5089) https://github.com/python/cpython/

[issue31804] multiprocessing calls flush on sys.stdout at exit even if it is None (pythonw)

Antoine Pitrou <pit...@free.fr> added the comment: @Pox, nevertheless, the fix committed in https://github.com/python/cpython/pull/4073 should also fix this issue. Do you disagree? -- ___ Python tracker <rep...@bugs.python.or

[issue28009] core logic of uuid.getnode() is broken for AIX - all versions

Antoine Pitrou <pit...@free.fr> added the comment: > What is the desired behavior, specifically, of uuid.getnode() - constant, or 'random'? I'm also certain getnode() is supposed to return a hardware-determined number (usually the MAC address of an Ethernet interface). A rand

<    4   5   6   7   8   9   10   11   12   13   >