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
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
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
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.
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/issue33
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
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/issue33
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/issue33
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/issue33
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/issue33
Antoine Pitrou added the comment:
I don't remember :-/ It's probably ok to increase the timeout, though.
--
___
Python tracker
<https://bugs.python.org/issue33
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
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
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, Pyth
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
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 tra
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
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/issue30
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/issue9
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/i
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
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: +pit
Change by Antoine Pitrou :
--
pull_requests: +6973
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue30654>
___
___
Python-
Antoine Pitrou added the comment:
Reopening for the 2.7 backport discussion.
--
status: closed -> open
___
Python tracker
<https://bugs.python.org/issu
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.o
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.
Antoine Pitrou added the comment:
Short of any bug in the patch, yes, it's stricly an improvement.
--
___
Python tracker
<https://bugs.python.org/issue30
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
<ht
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/issu
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/issue30
Change by Antoine Pitrou :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
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/issue30
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 r
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/issu
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/issue30
Change by Antoine Pitrou :
--
versions: +Python 3.8 -Python 2.7, Python 3.5
___
Python tracker
<https://bugs.python.org/issue30654>
___
___
Python-bugs-list m
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
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,
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/issu
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
Antoine Pitrou added the comment:
Did your PR fix the issue?
--
___
Python tracker
<https://bugs.python.org/issue33532>
___
___
Python-bugs-list mailin
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
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
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 a
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
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 un
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
se
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 San
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)&
Change by Antoine Pitrou <pit...@free.fr>:
--
priority: normal -> low
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33622>
___
__
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: -pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32458>
___
__
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: -pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33565>
___
__
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 tracke
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
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 tracke
Change by Antoine Pitrou <pit...@free.fr>:
--
priority: normal -> critical
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33612>
___
_
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +giampaolo.rodola, gregory.p.smith
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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 st
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
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
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" fie
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 m
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 benc
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
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: +
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.or
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
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
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).
--
___
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
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +christian.heimes, gregory.p.smith
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: -pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue22069>
___
__
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
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: op
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__ (
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
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 p
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.
-
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 -lut
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>
<
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
-lpyth
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
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
Antoine Pitrou <pit...@free.fr> added the comment:
This is expected, see issue33329.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bu
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/9d3627e311211a1b4abcda29c36fe4afe2
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(__
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#L10
Antoine Pitrou <pit...@free.fr> added the comment:
Posted a review now.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32608>
___
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,
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
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
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.
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 -P
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: op
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/
601 - 700 of 16564 matches
Mail list logo