[issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit
Antoine Pitrou added the comment: New changeset 20ae4c60258479a0732d12af292f422679444e2c by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-24596: Decref module in PyRun_SimpleFileExFlags() on SystemExit (GH-7918) (GH-8070) https://github.com/python/cpython/commit/20ae4c60258479a0732d12af292f422679444e2c -- ___ Python tracker <https://bugs.python.org/issue24596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24596] Script globals in a GC cycle not finalized when exiting with SystemExit
Antoine Pitrou added the comment: New changeset d8cba5d16f1333fd625726fc72e66afbd45b8d00 by Antoine Pitrou (Zackery Spytz) in branch 'master': bpo-24596: Decref module in PyRun_SimpleFileExFlags() on SystemExit (GH-7918) https://github.com/python/cpython/commit/d8cba5d16f1333fd625726fc72e66afbd45b8d00 -- ___ Python tracker <https://bugs.python.org/issue24596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34034] Python 3.7.0 multiprocessing forkserver ForkingPickler behaviour change
Antoine Pitrou added the comment: It could be many different things. The bottom line here, though, is that the Process class is not designed to be picklable (how would it work?), which is probably why you're seeing this. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue34034> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34009] Document Travis CI / Ubuntu 14.04 OpenSSL compatibility issues
Antoine Pitrou added the comment: Why should we mention Travis-CI at all? It's Travis-CI's job to document the binaries and runtimes they provide on each of their build environments. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue34009> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33939] Provide a robust O(1) mechanism to check for infinite iterators
Antoine Pitrou added the comment: I think being able to handle Ctrl-C would be the right solution here. Not handling Ctrl-C is a problem also for very long but non-infinite iterators. -- ___ Python tracker <https://bugs.python.org/issue33939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33939] Provide a robust O(1) mechanism to check for infinite iterators
Antoine Pitrou added the comment: Downside of __infinite_iterator__: another additional attribute to look up, and its functionality overlaps with __length_hint__. I'd rather have a special return value for __length_hint__ (e.g. -1, -2, whatever). -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33939> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33944] Deprecate and remove pth files
Antoine Pitrou added the comment: I would also add that editable installs should not break in the process. They are important. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33944> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33613] test_multiprocessing_fork: test_semaphore_tracker_sigint() fails with -W error
Antoine Pitrou added the comment: Is it possible to notify the ping / noop reply on stderr instead of introducing a new pipe? -- ___ Python tracker <https://bugs.python.org/issue33613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33945] concurrent.futures ProcessPoolExecutor submit() blocks on results being written
Antoine Pitrou added the comment: I'm not sure what happens exactly in your workload, but waiting 20 seconds when posting some data on an unbounded queue sounds enormous. -- nosy: +tomMoral ___ Python tracker <https://bugs.python.org/issue33945> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33613] test_multiprocessing_fork: test_semaphore_tracker_sigint() fails with -W error
Antoine Pitrou added the comment: We can easily add a 'NOOP' command to the semaphore tracker if it helps solve that issue. -- ___ Python tracker <https://bugs.python.org/issue33613> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33716] test_concurrent_futures.test_crash() failed on x86 Windows7 3.7
Antoine Pitrou added the comment: I don't remember :-/ It's probably ok to increase the timeout, though. -- ___ Python tracker <https://bugs.python.org/issue33716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33301] Add __contains__ to pathlib
Antoine Pitrou added the comment:
Not a good idea IMHO. Why would containment mean the existence of a file in a
directory? It could just as well mean that a certain path component is part of
the path.
Also I don't understand what would e.g. `Path('/usr/bar') in Path('/etc/foo')`
mean.
As for adding a .exists method to PurePath, I think you're missing the point of
PurePath here (i.e. its operations *don't* do any IO whatsoever).
--
nosy: +pitrou
___
Python tracker
<https://bugs.python.org/issue33301>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32388] Remove cross-version binary compatibility
Antoine Pitrou added the comment: > Does it mean that Python 3.8 wil crash on loading C extensions compiled on > Python older than this version? What makes you think that it would be otherwise be able to load and execute such C extensions without any bugs? There is no ABI except the stable ABI, and tp_flags isn't part of the stable ABI. PS : tp_finalize is in Python 3.4, but that doesn't really matter. -- ___ Python tracker <https://bugs.python.org/issue32388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33895] LoadLibraryExW called with GIL held can cause deadlock
Antoine Pitrou added the comment: Do you want to submit a PR for this? You can take a look at our developer's guide if you're new to contributing to Python: https://devguide.python.org/ -- nosy: +pitrou stage: -> needs patch type: -> behavior versions: -Python 2.7, Python 3.4, Python 3.5 ___ Python tracker <https://bugs.python.org/issue33895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33884] [multiprocessing] Multiprocessing in spawn mode doesn't work when the target is a method in a unittest.TestCase subclass, when run either with unittest or with pytest
Antoine Pitrou added the comment: While this is limitation of the spawn and forkserver modes, I don't see how this is a bug. Also, as you point out, making the method a classmethod or staticmethod works around the limitation. -- resolution: -> not a bug stage: -> resolved status: open -> pending ___ Python tracker <https://bugs.python.org/issue33884> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33858] A typo in multiprocessing documentation
Antoine Pitrou added the comment: Ok, I've backported to 3.6 in https://github.com/python/cpython/pull/7721 -- components: +Library (Lib) resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior ___ Python tracker <https://bugs.python.org/issue33858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33841] lock not released in threading.Condition
Antoine Pitrou added the comment: The `waiter` lock is always removed from `self._waiters` at the end of wait() (either by notify() or by wait() itself), so there's no point in releasing it a second time before destruction. I'm closing this as it's not a bug. -- nosy: +pitrou, tim.peters resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33841> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Antoine Pitrou added the comment: I would be ok with reverting to the non-HLE variants. Does anyone want to test the performance implications on TSX-enabled hardware? -- ___ Python tracker <https://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9141] Allow objects to decide if they can be collected by GC
Antoine Pitrou added the comment: It's hard to say as I never fully understood the underlying intent. Perhaps Kristján or some other developer who better understood than me can chime in. -- ___ Python tracker <https://bugs.python.org/issue9141> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: So this is in 2.7 finally. Closing again. -- stage: patch review -> resolved status: open -> closed versions: +Python 2.7 ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: New changeset ded666ff0ce44785a495ff89b676ca68e4cc08e8 by Antoine Pitrou in branch '2.7': [2.7] bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7347) https://github.com/python/cpython/commit/ded666ff0ce44785a495ff89b676ca68e4cc08e8 -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33738] PyIndex_Check conflicts with PEP 384
Antoine Pitrou added the comment: > related personal note - does someone know what happened to Martin? I don't think anything bad happened. He still seems to be teaching: http://www.beuth-hochschule.de/people/detail/1398/ -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33738> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Change by Antoine Pitrou : -- pull_requests: +6973 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: Reopening for the 2.7 backport discussion. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30416] constant folding opens compiler to quadratic time hashing
Antoine Pitrou added the comment: I vote for "won't fix". 2.7 has lived long enough with this issue, AFAIU. And it won't be triggered by regular code. -- ___ Python tracker <https://bugs.python.org/issue30416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33739] pathlib: Allow ellipsis to appear after "/" to navigate to parent path
Antoine Pitrou added the comment: I've just tried, "..." doesn't seem to mean anything on the Windows CLI. But I agree with the reservation that having "..." mean something different than ".." is a recipe for confusion. -- nosy: +steve.dower ___ Python tracker <https://bugs.python.org/issue33739> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: Short of any bug in the patch, yes, it's stricly an improvement. -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33650] asyncio: Prohibit adding a signal handler for SIGCHLD
Antoine Pitrou added the comment: Some people may have reasons to do that (for example: they write their own subprocess implementation). I suggest emitting a warning rather than forbidding it. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33650] asyncio: Prohibit adding a signal handler for SIGCHLD
Change by Antoine Pitrou : -- title: Prohibit adding a signal handler for SIGCHLD -> asyncio: Prohibit adding a signal handler for SIGCHLD ___ Python tracker <https://bugs.python.org/issue33650> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: I'm nosy'ing Benjamin, the 2.7 release manager, in case he wants to comment on desirability of this bugfix in Python 2.7. -- nosy: +benjamin.peterson ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: New changeset 1d5198fd41ad9185e9e6b3aa595769c3693d57be by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7307) https://github.com/python/cpython/commit/1d5198fd41ad9185e9e6b3aa595769c3693d57be -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33725] High Sierra hang when using multi-processing
Antoine Pitrou added the comment: I understand that Apple, with their limited resources, cannot spend expensive engineer manpower on improving POSIX support in macOS . In any case, I'm unsure this bug can be fixed at the Python level. If macOS APIs don't like fork(), they don't like fork(), point bar. As Ronald says, on 3.x you should use "forkserver" (for multiple reasons, not only this issue). On 2.7 you're stuck dealing with the issue by yourself. -- ___ Python tracker <https://bugs.python.org/issue33725> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: New changeset 623b439abebc913bc416d92f38fe371e84b0276b by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) (GH-7306) https://github.com/python/cpython/commit/623b439abebc913bc416d92f38fe371e84b0276b -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: Ok, I think it go into 3.7.0 after all. 3.7.1 wouldn't get more testing before it's released anyway. -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: > For 3.7, we are very close to the final release. It doesn't give much time to > users to test the new behavior That's a fair point. What's the procedure here? If I backport the fix to the 3.7 branch, will it go straight into the 3.7.0 release or will it be deferred to 3.7.1? @Ned -- nosy: +ned.deily ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: > So if an application has its own signal handler, Python replaces it... You have it backwards. Please read the bug report. -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: I'd rather not backport this to 2.7 as it's quite late in the maintenance cycle and I'd like to avoid any regressions there. -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Change by Antoine Pitrou : -- versions: +Python 3.8 -Python 2.7, Python 3.5 ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30654] signal module always overwrites SIGINT on interpreter shutdown
Antoine Pitrou added the comment: New changeset e905c84494526363086f66a979e317e155bf9536 by Antoine Pitrou (pkerling) in branch 'master': bpo-30654: Do not reset SIGINT handler to SIG_DFL in finisignal (GH-7146) https://github.com/python/cpython/commit/e905c84494526363086f66a979e317e155bf9536 -- ___ Python tracker <https://bugs.python.org/issue30654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou added the comment: Here is a micro-benchmark of GC overhead: * before: $ ./python -m timeit -s "import gc, doctest, ftplib, asyncio, email, http.client, pydoc, pdb, fractions, decimal, difflib, textwrap, statistics, shutil, shelve, lzma, concurrent.futures, telnetlib, smtpd, tkinter.tix, trace, distutils, pkgutil, tabnanny, pickletools, dis, argparse" "gc.collect()" 100 loops, best of 5: 2.41 msec per loop * after: $ ./python -m timeit -s "import gc, doctest, ftplib, asyncio, email, http.client, pydoc, pdb, fractions, decimal, difflib, textwrap, statistics, shutil, shelve, lzma, concurrent.futures, telnetlib, smtpd, tkinter.tix, trace, distutils, pkgutil, tabnanny, pickletools, dis, argparse" "gc.collect()" 100 loops, best of 5: 2.52 msec per loop So it's a 4% slowdown, but GC runs themselves are a minor fraction of usual programs' runtime, so I'm not sure that matters. Though it would be better to test on an actual GC-heavy application. -- ___ Python tracker <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33713] memoryview can set an exception in tp_clear
Antoine Pitrou added the comment: Yes, tp_clear can be called with refcount > 0. It's exactly why it's separate from tp_dealloc, actually :-) -- ___ Python tracker <https://bugs.python.org/issue33713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33713] memoryview can set an exception in tp_clear
Antoine Pitrou added the comment: Serhiy is right about the theoretical concern here. However, it's probably quite difficult to find a concrete situation where this occurs, because we're talking about mbuf_clear and the managerbuffer object can't really get involved in a reference cycle by itself (not in normal use anyway): the memoryview object does, but it's a different thing. By the way: PyBuffer_Release() returns void, so IMO it's a bug if it can return with an exception set. We should fix that rather than focus on mbuf_clear(). -- ___ Python tracker <https://bugs.python.org/issue33713> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33532] test_multiprocessing_forkserver: TestIgnoreEINTR.test_ignore() fails on Travis CI
Antoine Pitrou added the comment: Did your PR fix the issue? -- ___ Python tracker <https://bugs.python.org/issue33532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33607] [subinterpreters] Explicitly track object ownership (and allocator).
Antoine Pitrou added the comment: I agree with Victor, we shouldn't add PyObject fields that only have use in certain (minority) situations. The idea of tracking per arena will be non-trivial to implement, as only small objects (smaller than 512 bytes) use our own allocator; larger objects go to the system allocator. Can I ask why you're considering this? I thought you didn't want to transfer ownership between interpreters. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue33607> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou added the comment: As I said, the code just defers to "perf". And you should have tested that :-) I'm not really interested in checking it. All I know is that the very old code (inherited from Unladen Swallow) did memory tracking correctly. And I have no reason to disbelieve the numbers I posted. -- ___ Python tracker <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou added the comment: > I'm not sure that the code tracking the memory usage in performance works Why wouldn't it? It certainly gives believable numbers (see above). And it seems to defer to your own "perf" tool anyway. > perf has two options: --track-memory and --tracemalloc, see the doc: I don't think tracemalloc is a good tool to compare memory usage, as it comes with its own overhead. Also it won't account for issues such as memory fragmentation. > In the 3 cases, perf saves the *peak* of the memory usage. Well, yes, that's the point, thank you. -- ___ Python tracker <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou added the comment: Ok, I ran a subset of the benchmarks to record their memory footprint and got these results: master-mem.perf === Performance version: 0.6.2 Python version: 3.8.0a0 (64-bit) revision 73cbe7a Report on Linux-4.15.0-22-generic-x86_64-with-glibc2.9 Number of logical CPUs: 16 Start date: 2018-05-29 16:54:24.964539 End date: 2018-05-29 17:04:05.608437 methane-mem.perf Performance version: 0.6.2 Python version: 3.8.0a0 (64-bit) revision 16c66ca Report on Linux-4.15.0-22-generic-x86_64-with-glibc2.9 Number of logical CPUs: 16 Start date: 2018-05-29 17:15:00.936857 End date: 2018-05-29 17:24:33.755119 ++-+--+---++ | Benchmark | master-mem.perf | methane-mem.perf | Change| Significance | ++=+==+===++ | 2to3 | 7121.8 kB | 6944.4 kB| 1.03x smaller | Significant (t=31.59) | ++-+--+---++ | chameleon | 15.7 MB | 15.3 MB | 1.02x smaller | Significant (t=24.25) | ++-+--+---++ | html5lib | 20.1 MB | 19.4 MB | 1.04x smaller | Significant (t=67.15) | ++-+--+---++ | json_dumps | 8282.2 kB | 8021.4 kB| 1.03x smaller | Significant (t=234.01) | ++-+--+---++ | json_loads | 7671.2 kB | 7494.0 kB| 1.02x smaller | Significant (t=37.43) | ++-+--+---++ | pickle | 7883.4 kB | 7698.6 kB| 1.02x smaller | Significant (t=28.64) | ++-+--+---++ | pickle_pure_python | 7867.4 kB | 7680.0 kB| 1.02x smaller | Significant (t=48.64) | ++-+--+---++ | sqlalchemy_declarative | 18.4 MB | 17.9 MB | 1.03x smaller | Significant (t=132.47) | ++-+--+---++ | sqlalchemy_imperative | 17.8 MB | 17.3 MB | 1.03x smaller | Significant (t=128.94) | ++-+--+---++ | tornado_http | 24.5 MB | 24.0 MB | 1.02x smaller | Significant (t=7.99) | ++-+--+---++ | unpickle | 7883.2 kB | 7694.2 kB| 1.02x smaller | Significant (t=31.19) | ++-+--+---++ | unpickle_pure_python | 7891.6 kB | 7699.4 kB| 1.02x smaller | Significant (t=63.68) | ++-+--+---++ | xml_etree_generate | 12.0 MB | 11.5 MB | 1.04x smaller | Significant (t=26.07) | ++-+--+---++ | xml_etree_iterparse| 11.8 MB | 11.3 MB | 1.04x smaller | Significant (t=146.82) | ++-+--+---++ | xml_etree_parse| 11.6 MB | 11.2 MB | 1.03x smaller | Significant (t=116.08) | ++-+--+---++ | xml_etree_process | 12.3 MB | 12.0 MB | 1.02x smaller | Significant (t=49.04) | ++-+--+---++ -- ___ Python tracker <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou added the comment: > Are you sure that all memory allocators align at least on 8 bytes (to give up > 3 unused bits)? If they don't then a simple double array will end up unaligned. It's not impossible but extremely unlikely. -- ___ Python tracker <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33632] undefined behaviour: signed integer overflow in threadmodule.c
New submission from Antoine Pitrou <pit...@free.fr>: Modules/_threadmodule.c:52:47: runtime error: signed integer overflow: 2387971499048 + 92233720360 cannot be represented in type 'long' -- components: Library (Lib) messages: 317545 nosy: pitrou priority: normal severity: normal status: open title: undefined behaviour: signed integer overflow in threadmodule.c type: behavior versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33632> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33627] test-complex of test_numeric_tower.test_complex() crashes intermittently on Ubuntu buildbots
Antoine Pitrou <pit...@free.fr> added the comment: Those two builders are using Ubuntu 14.04 specifically (with different CPU architectures). I couldn't reproduce on my 16.04 machine. Perhaps something odd on 14.04? Do we have builds with Adress Sanatizer or Undefined Behavior Sanitizer? -- nosy: +gregory.p.smith, pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33627> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33621] repr(threading._DummyThread) always fails.
Antoine Pitrou <pit...@free.fr> added the comment: Can you post the actual exception you are getting? Here I have: >>> import threading >>> repr(threading._DummyThread()) '<_DummyThread(Dummy-1, started daemon 140345620215552)>' -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33622] Fix errors handling in the garbage collector
Change by Antoine Pitrou <pit...@free.fr>: -- priority: normal -> low ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33622> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32458] test_asyncio: test_start_tls_server_1() fails randomly
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32458> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31463] test_multiprocessing_fork hangs test_subprocess
Antoine Pitrou <pit...@free.fr> added the comment: Let's take another look at the issue: why does test_subprocess need to know about all child processes, rather than those that were launched during test_subprocess? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31463> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33612] Assertion failure in PyThreadState_Clear
Antoine Pitrou <pit...@free.fr> added the comment: Le 23/05/2018 à 13:57, STINNER Victor a écrit : > > I agree that in a perfect world, Python should cleanup everything properly, > but in the current world, daemon threads and fork are a mess full of corner > cases like this one. For now, we don't know for sure that it's a cleanup issue. What if it's something else? I agree that, if it's simply a cleanup issue with daemon threads, we can remove the assertion. But perhaps we should first diagnose the issue. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33612] Assertion failure in PyThreadState_Clear
Antoine Pitrou <pit...@free.fr> added the comment: Yes, simply removing the assertion feels more like a copout than an actual fix. (perhaps it *is* the right fix to the issue, but it would be nice to find out why :-)) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33612] Assertion failure in PyThreadState_Clear
Change by Antoine Pitrou <pit...@free.fr>: -- priority: normal -> critical ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33603] Subprocess Thread handles grow with each call and aren't released until script ends
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +giampaolo.rodola, gregory.p.smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou <pit...@free.fr> added the comment: Le 22/05/2018 à 17:31, INADA Naoki a écrit : > > INADA Naoki <songofaca...@gmail.com> added the comment: > > $ ./python-gc -c 'import asyncio,sys; sys._debugmallocstats()' Thanks. You can also collect peak memory stats during the benchmark suite, though the numbers may be approximate. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33597] Compact PyGC_Head
Antoine Pitrou <pit...@free.fr> added the comment: Interesting. Do you have any comparisons on memory footprint too? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33597> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33589] Remove dummy member in GCHead
Antoine Pitrou <pit...@free.fr> added the comment: I'm fine with an anonymous struct. Is it standard C these days? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33589] Remove dummy member in GCHead
Antoine Pitrou <pit...@free.fr> added the comment: Short of adding a `tp_alignment`, though, I think we should not make things harder for the common cases. This means we should probably keep the "double" member to ensure that extension types that have a "double" field in their object struct have the right alignment by default. "long double" is much rarer and people who need it can workaround alignment issues by hand (for example by issuing memcpy() calls). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33589] Remove dummy member in GCHead
Antoine Pitrou <pit...@free.fr> added the comment: >From the linked changeset message: > unless anyone knows of a platform where ssize_t is 4 bytes? That's most 32-bit platforms, right? Basically, size_t and ssize_t are pointer-sized except on some rare architectures. > A more correct non-hacky alternative if any alignment issues are still found > would be to use a compiler specific alignment declaration on the structure > and determine which value to use at configure time. AFAIU, the problem is not alignment of the PyGC_Head structure (it's always sufficiently aligned for its pointer-sized members) but alignment of the user-defined object that follows it. The underlying issue IMO is we're trying to force a one-size-fits-all alignment for user-defined object structs that we know nothing about (but might contain something like a "long double" or, worse, some SIMD values). Perhaps PyTypeObject should grow a `tp_alignment` field. -- nosy: +gregory.p.smith, serhiy.storchaka, tim.peters ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33589> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33583] PyObject_GC_Resize() doesn't relink GCHead
Antoine Pitrou <pit...@free.fr> added the comment: I think we can simply document it. I don't think anyone has silently buggy code, since it would probably cause a crash as soon as the chain of objects is walked. If we want to fix PyObject_GC_Resize(), we should check that benchmarks are unaffected. -- nosy: +pitrou, serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33583> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().
Antoine Pitrou <pit...@free.fr> added the comment: Then it would be nice to post benchmarks using asyncio.gather() (on something not too trivial perhaps). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33521] Add 1.32x faster C implementation of asyncio.isfuture().
Antoine Pitrou <pit...@free.fr> added the comment: What is the impact on a regular application? The fact that a micro-benchmark becomes X% faster isn't very interesting itself, especially as the original function, at less than 1µs per call, is already very fast. -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33521> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19251] bitwise ops for bytes of equal length
Antoine Pitrou <pit...@free.fr> added the comment: Please, let's have this API discussion outside of the bug tracker. This deserves a PEP. Also because I have an alternative API to suggest :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33565] strange tracemalloc results
Antoine Pitrou <pit...@free.fr> added the comment: Can you post a reproducer that doesn't involve S3? -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19251] bitwise ops for bytes of equal length
Antoine Pitrou <pit...@free.fr> added the comment: Le 17/05/2018 à 18:20, Nick Coghlan a écrit : > > The question is whether we might be able to avoid some > bytes->Python-objects->bytes cycles if there were a few more > contiguous-binary-data-centric operations on bytes and/or memoryview (similar > to the way the ASCII-centric operations on bytes and bytearray help to avoid > bytes->text->bytes cycles). Can you elaborate on your question? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue19251> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21145] Add the @cached_property decorator
Antoine Pitrou <pit...@free.fr> added the comment: I agree this would be a useful addition to the stdlib. The code might seem reasonably short, but implementing new descriptors is an advanced topic (I'd rather avoid it myself). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33451] Start pyc file lock the file
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +brett.cannon, eric.snow, ncoghlan, paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33526] hashlib leak on import
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: +christian.heimes, gregory.p.smith ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33522] Enable CI builds on Visual Studio Team Services
Antoine Pitrou <pit...@free.fr> added the comment: Can you explain what Visual Studio Team Services is? -- nosy: +pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22069] TextIOWrapper(newline="\n", line_buffering=True) mistakenly treat \r as a newline
Change by Antoine Pitrou <pit...@free.fr>: -- nosy: -pitrou ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28055] pyhash's siphash24 assumes alignment of the data pointer
Antoine Pitrou <pit...@free.fr> added the comment: Indeed the memcpy() approach is the common idiom in such situations, and sounds like the right thing. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4934] tp_del and tp_version_tag undocumented
Antoine Pitrou <pit...@free.fr> added the comment: Both tp_del and tp_version_tag are for internal use. Besides, tp_del is obsolete as I mentioned above. So I'm going to close the issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue4934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4934] tp_del and tp_version_tag undocumented
Antoine Pitrou <pit...@free.fr> added the comment: The reason tp_del has remained undocumented is that it's now obsolete. You should use tp_finalize instead: https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_finalize tp_finalize is roughly the C equivalent of __del__ (tp_del was something else, despite the name). -- versions: +Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue4934> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33444] Memory leak/high usage on copy in different thread
Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33444] Memory leak/high usage on copy in different thread
Antoine Pitrou <pit...@free.fr> added the comment: Yes, this looks surprising, but there is no memory leak here, just memory fragmentation in the glibc allocator. This is the program I used to diagnose it: https://gist.github.com/pitrou/6c5310d4c721436165666044e3c31158 At the end the program prints glibc allocator stats as returned by mallinfo() (see http://man7.org/linux/man-pages/man3/mallinfo.3.html). On my system, the process takes 480 MB RSS and "fordblks" (the total number of bytes in free blocks) is 478 MB. However, "keepcost" (the releasable free space) is only 30 MB. The rest is probably interspersed with internal interpreter structures that have stayed alive. The fragmentation seems to depend on the number of threads. If you start the executor with only one thread, memory consumption is much lower. This makes sense: by ensuring all operations happen in order with little concurrency, we minimize the chance that short-lived data gets interspersed with longer-lived data. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33444> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33439] python-config.py should be part of the stdlib
New submission from Antoine Pitrou <pit...@free.fr>: Rather than (or in addition to) being a standalone script, python-config should be invokable as a stdlib module, e.g. "python -m sysconfig.config". This would prevent the risk of invoking the wrong script on PATH. -- components: Build, Library (Lib) messages: 316264 nosy: barry, doko, ncoghlan, pitrou priority: normal severity: normal status: open title: python-config.py should be part of the stdlib type: enhancement versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33439> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33438] pkg-config file misses flags for static linking
Antoine Pitrou <pit...@free.fr> added the comment: Note that both implementations of python-config give the right information: $ ./python python-config.py --libs -lpython3.7m -lpthread -ldl -lutil -lm $ sh python-config --libs -lpython3.7m -lpthread -ldl -lutil -lm -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33438] pkg-config file misses flags for static linking
Antoine Pitrou <pit...@free.fr> added the comment: (correction: in the first message, I meant "on Linux" not "on Windows". Of course :-)) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33438] pkg-config file misses flags for static linking
Antoine Pitrou <pit...@free.fr> added the comment: $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --static python $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --libs python -L/home/antoine/cpython/37/usr/lib -lpython3.7m $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --libs-only-l python -lpython3.7m $ PKG_CONFIG_PATH=`pwd`/Misc pkg-config --libs-only-other python $ -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33438] pkg-config file misses flags for static linking
New submission from Antoine Pitrou <pit...@free.fr>: Our pkg-config misses flags for static linking with libpythonXX.a, such as "-lpthread -lutil -lrt" on Windows. For dynamic linking, this is not a problem since libpythonXX.so links explicitly against those system libraries. -- components: Build messages: 316258 nosy: barry, doko, pitrou priority: normal severity: normal status: open title: pkg-config file misses flags for static linking type: behavior versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()
Antoine Pitrou <pit...@free.fr> added the comment: Yes, but we're not losing anything by being overly cautious. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()
Antoine Pitrou <pit...@free.fr> added the comment: This is expected, see issue33329. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()
Change by Antoine Pitrou <pit...@free.fr>: -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33332] Expose valid signal set (sigfillset()): add signal.valid_signals()
Antoine Pitrou <pit...@free.fr> added the comment: New changeset 9d3627e311211a1b4abcda29c36fe4afe2c46532 by Antoine Pitrou in branch 'master': bpo-2: Add signal.valid_signals() (GH-6581) https://github.com/python/cpython/commit/9d3627e311211a1b4abcda29c36fe4afe2c46532 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue2> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33407] Implement Py_DEPRECATED() macro for Visual Studio
Antoine Pitrou <pit...@free.fr> added the comment: In Arrow we use the following: #if __cplusplus <= 201103L # ifdef __GNUC__ # define ARROW_DEPRECATED(...) __attribute__((deprecated(__VA_ARGS__))) # elif defined(_MSC_VER) # define ARROW_DEPRECATED(...) __declspec(deprecated(__VA_ARGS__)) # else # define ARROW_DEPRECATED(...) # endif #else # define ARROW_DEPRECATED(...) [[deprecated(__VA_ARGS__)]] #endif -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33407> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
Antoine Pitrou <pit...@free.fr> added the comment: multiprocessing semaphores support Ctrl-C under Windows, so it should be doable for regular locks as well (notice the `sigint_event`): https://github.com/python/cpython/blob/master/Modules/_multiprocessing/semaphore.c#L109-L146 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32608] Incompatibilities with the socketserver and multiprocessing packages
Antoine Pitrou <pit...@free.fr> added the comment: Posted a review now. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
Antoine Pitrou <pit...@free.fr> added the comment: > I'm guessing this is because of the perceived performance impact? The problem is polling is pretty detrimental to power saving on modern CPUs. There might also be a performance impact that makes things worse :-) More generally, we really would like locks to be interruptible under Windows, as it would be useful in many more situations than joining threads. Unfortunately, as you have discovered we have several lock implementations for Windows right now. The SRWLock one is probably difficult to make interruptible, but it's never enabled by default. The Semaphore one looks legacy, so could perhaps be removed. Remains the condition variable-based implementation. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
Antoine Pitrou <pit...@free.fr> added the comment: > One way to possibly make this work (although perhaps not as clean as may be > desired) would be to add polling logic into the thread_nt.h version of > PyThread_acquire_lock_timed. I think adding polling to such a widely-used primitive is out of question. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32608] Incompatibilities with the socketserver and multiprocessing packages
Antoine Pitrou <pit...@free.fr> added the comment: Hi Michael, sorry, I haven't had a chance yet. I'll try to make some time soon, I hope you don't mind the delay :-S -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32608> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21822] KeyboardInterrupt during Thread.join hangs that Thread
Antoine Pitrou <pit...@free.fr> added the comment: Thanks for the update. Since I still can't reproduce on Linux, perhaps you (or one of our resident Windows experts) can try to propose a patch fixing the issue? -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly
Antoine Pitrou <pit...@free.fr> added the comment: Oscar, the patch posted here needs updating for the latest git master. If you want to avoid this issue, you can also use concurrent.futures where the issue is fixed. -- stage: -> needs patch versions: +Python 3.8 -Python 3.5 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue22393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33329] sigaddset() can fail on some signal numbers
Antoine Pitrou <pit...@free.fr> added the comment: Miro, this should be fixed now. Please reopen if it isn't. The sigfillset() functionality will be exposed to Python users in bpo-2. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33329] sigaddset() can fail on some signal numbers
Antoine Pitrou <pit...@free.fr> added the comment: New changeset b0ca398cabd2d2ea2d66fa50b08e297a60388c75 by Antoine Pitrou in branch '3.6': [3.6] bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (GH-6582) https://github.com/python/cpython/commit/b0ca398cabd2d2ea2d66fa50b08e297a60388c75 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
