Antoine Pitrou <pit...@free.fr> added the comment:
Seems to be in inttypes.h:
https://www.ibm.com/support/knowledgecenter/en/ssw_aix_71/com.ibm.aix.files/inttypes.h.htm
--
___
Python tracker <rep...@bugs.python.org>
<https://
Antoine Pitrou <pit...@free.fr> added the comment:
I don't think the overall gain is meaningful. I'd rather not add too many
special cases in the framing code.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
> Humm, this feature doesn't work with C implementation.
What do you mean?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
Definitely! Thank you for your contribution :-)
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<
Antoine Pitrou <pit...@free.fr> added the comment:
Michael, does AIX have uint32_t? If so, we could happily drop the unsigned32
reference.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
The AIX-specific code was contributed by Michael Felt in issue32399.
--
nosy: +Michael.Felt, pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
This non-trivial issue has been fixed now, thanks to Thomas' patch. Thank you
Thomas!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 94459fd7dc25ce19096f2080eb7339497d319eb0 by Antoine Pitrou
(Thomas Moreau) in branch 'master':
bpo-31699 Deadlocks in `concurrent.futures.ProcessPoolExecutor` with pickling
error (#3895)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
The threading.Timer class is in my experience little used, for two reasons:
1) it's not very flexible (no periodic calls, no restart...)
2) it's not efficient (as it creates a new thread for each timer)
3) (third optional reason
Antoine Pitrou <pit...@free.fr> added the comment:
> While I like faster startup time, I don't know 4% speed up is worth enough
> for this complexity.
There's no magic bullet that I know of to reduce startup time by a large
amount. So we're left with optimizing progressively. Fo
Antoine Pitrou <pit...@free.fr> added the comment:
I see, so I should be able to reuse tp_cache for this PR.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Well, on the other hand, the change you're proposing is hardly necessary,
unless it actually demonstrates a noticeable improvement on some workload. So
perhaps we should leave the peepholer alone until someone has a bette
Antoine Pitrou <pit...@free.fr> added the comment:
> But some peephole optimizations will work with the intermediate fixed-size
> representations used by the compiler, before generating the concrete bytecode.
Then perhaps the goal should be to make the peephole operate on that
Antoine Pitrou <pit...@free.fr> added the comment:
What exactly is tp_cache? Apparently it was added by Guido in
https://github.com/python/cpython/commit/687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2
but never used (at least officially).
commit 687ae00460da9cac04eb1ba8f6f5ab4db25fbfc2
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +Ray Donnelly
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue29708>
___
_
Antoine Pitrou <pit...@free.fr> added the comment:
Le 02/01/2018 à 18:13, Mark Shannon a écrit :
>
> Rather than go around in circles any more, I suggest that we merge Serhiy's
> PR (PR 5006). I can then cherry-pick my commits to clean up the
> implementation of the `with` s
Change by Antoine Pitrou <pit...@free.fr>:
--
status: pending -> closed
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32480>
___
_
Antoine Pitrou <pit...@free.fr> added the comment:
Yes, so `rm -rf` is quadratic on my SSD too...
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
> With fixed deltas, it is not too hard to construct an algorithm to
determine the correct stack size. The presence of JSR-style finally
blocks complicates things a little, but not that much.
Any chance you can put that patch somewhe
Antoine Pitrou <pit...@free.fr> added the comment:
> I just worked on it.
I meant Mark's PR :-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Antoine Pitrou <pit...@free.fr> added the comment:
I took a quick look at Mark's PR. The main thing going for it IMHO is that it
produces simpler bytecode: it removes the complicated with/finally-related
opcodes, while Serhiy's has non-trivial END_FINALLY and POP_FINALLY.
It would b
Antoine Pitrou <pit...@free.fr> added the comment:
Why don't you use BufferedReader.peek()?
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
So we now have three competing PRs... each of which is not trivial. It would be
nice if somehow there could be some conciliation, or at least a synthetic
comparison. I don't think I want to review all three proposals (and I already
spen
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 14709144b521b9916f798a43aac9dc44fd44f6ca by Antoine Pitrou in
branch 'master':
bpo-32468: Better frame repr() (#5067)
https://github.com/python/cpython/commit/14709144b521b9916f798a43aac9dc44fd
Antoine Pitrou <pit...@free.fr> added the comment:
Did you try to sync and flush caches before running `rm -r`?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Antoine Pitrou <pit...@free.fr>:
Currently, a generator or coroutine's repr looks like this:
>>> gen
It could instead be something like:
>>> gen
(replace "suspended" with "running" or "closed" depending on t
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +4941
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +benjamin.peterson
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32468>
___
New submission from Antoine Pitrou <pit...@free.fr>:
Currently a frame's repr looks like this:
>>> f
It would be more helpful if it displayed something like:
>>> f
--
components: Interpreter Core
messages: 309298
nosy: pitrou, serhiy.storchaka, yselivanov
p
Antoine Pitrou <pit...@free.fr> added the comment:
Sounds like good hygiene to me, though I didn't know that "tentative
declarations" were legacy (don't they simply mean the variable gets an
arbitrary initialization value?).
Antoine Pitrou <pit...@free.fr> added the comment:
First, I would count Google in the extremely skilled category :-)
(cc'ing Thomas so that he can chime in)
Second, if someone are doing a custom build of Python, they are very likely
modifying something else than Modules/Setup (*
Antoine Pitrou <pit...@free.fr> added the comment:
> It is annoying that there is no documentation on the build process that can
> be modified to describe the deprecation in details. Do you think a What'sNew
> entry is sufficient ?
Yes, I think so. Also my hope is to r
Antoine Pitrou <pit...@free.fr> added the comment:
Note the use case we're trying to preserve here is probably extremely rare.
I've never needed it myself, and I've never seen it done by anyone else. We're
talking about a very small demographics who's probably skilled enough to
Antoine Pitrou <pit...@free.fr> added the comment:
I would hope to simplify the build process, not to complicate it. In other
words, I think the PR is a step in the wrong direction, *except* if using
Setup.dist becomes the default and the other way is clearly marked depr
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 0d3ccb4395cccb11a50289c84c9a0dbbac03c647 by Antoine Pitrou
(Michael Felt) in branch 'master':
bpo-32399: Starting with AIX6.1 there is support in libc.a for uuid (RFC4122)
(#4974)
https://github.com/python/cpython/
New submission from Antoine Pitrou <pit...@free.fr>:
It seems test_asyncio fails sporadically on AppVeyor:
https://ci.appveyor.com/project/python/cpython/build/3.7.0a0.10081#L2650
==
ERROR: test_start_tls_se
Antoine Pitrou <pit...@free.fr> added the comment:
> Regardless, it'd be nice to have it available in the stdlib so it could be
> used if deemed useful.
Agreed.
> Signals are process global state, no thread compatible library can rightfully
> take
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
Antoine Pitrou <pit...@free.fr> added the comment:
I don't think filesystem-specific optimizations belong in the Python stdlib.
Python is compatible with multiple operating systems, including Windows, macOS,
Android, many POSIX variants. It would be much better if this were
Antoine Pitrou <pit...@free.fr> added the comment:
> Whether the small speed difference is worth worrying about is a different
> matter.
I don't think so. Though one could run the benchmarks suite to get an idea of
the impact on rea
Antoine Pitrou <pit...@free.fr> added the comment:
I'm ok with turning the warning into an error. Does anyone object here?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Le 29/12/2017 à 12:48, Mark Shannon a écrit :
>
> Why all these competing pull requests? It does feel like my original patch
> has been hijacked.
The original patch had a number of issues which needed to be fixed (in
addition
Antoine Pitrou <pit...@free.fr> added the comment:
Also see how the forkserver module does without it:
https://github.com/python/cpython/blob/master/Lib/multiprocessing/forkserver.py#L146
Reading Jean-Paul's messages in https://bugs.python.org/issue8407, I'm unclear
what is required t
Antoine Pitrou <pit...@free.fr> added the comment:
See also https://bugs.python.org/issue12304
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Le 29/12/2017 à 06:26, Neil Schemenauer a écrit :
>
> I wonder if I should drop PR 4682.
My main criterion (apart from performance issues which don't seem to
exist) for choosing between the two PRs would be implementation
complex
Antoine Pitrou <pit...@free.fr> added the comment:
Yes, those benchmarks look fine. Have you tried with the benchmarks suite?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Indeed, we probably want a flexible handshake mechanism. This needn't be very
optimized: probably a magic number followed by a JSON-encoded dict is
sufficient.
(of course, several years down the road, someone will engineer a dow
Antoine Pitrou <pit...@free.fr> added the comment:
> Personally I'll go for a single Setup file (No .dist, no .local, no copy),
> that one can modify and commit, delegating the pain of merging to git, as I
> prefer simple solutions.
+1 for this.
--
nosy: +bar
Antoine Pitrou <pit...@free.fr> added the comment:
> +1 - do you have any thoughts on that?
I think the current scheme may have been useful at a time where DVCS didn't
exist. You would maintain an unversioned copy of Modules/Setup.dist in your
work-tree. Nowadays you can fork a gi
Antoine Pitrou <pit...@free.fr> added the comment:
I'd really like it if we could get rid of the Setup/Setup.dist thing. It's a
distraction to have to type `cp -f Modules/Setup.dist Modules/Setup` from time
to time... even though I have never customized the Setup file.
-
Antoine Pitrou <pit...@free.fr> added the comment:
Does this approach allow test_uuid to pass for you?
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Keep in mind _uuid is an optional C extension that is used to accelerate the
uuid module when available. It doesn't bring any additional functionality by
itself.
--
nosy: +pitrou
___
Antoine Pitrou <pit...@free.fr> added the comment:
That's basically exact. Actually, there is no ABI guarantee at all (when not
using the stable ABI), just a best effort for advanced users who know what
they're doing.
Actually, this PR stems from Nathaniel's message here:
Antoine Pitrou <pit...@free.fr> added the comment:
Thanks for the heads-up Steve.
> Considering a .pyd file linking against pythonXY.dll is only going to load in
> the context of that version anyway, this is hardly urgent.
I see. That's a good argument for keeping the current ext
Antoine Pitrou <pit...@free.fr> added the comment:
I don't really understand your proposal, so it's hard to answer :-) Perhaps you
can try to implement it so that we can compare?
--
___
Python tracker <rep...@bugs.python.or
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
Antoine Pitrou <pit...@free.fr> added the comment:
cc'ing people for the pip/PyPI aspects of this.
--
nosy: +Marcus.Smith, dstufft
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Here's another idea: have a new type field (a tp_something) that exposes the GC
priority for this type. It could be an integer between -8 and 7, for example
(0 being the default). Then tp_finalize would be called in sorted priority
Antoine Pitrou <pit...@free.fr> added the comment:
Closing this issue in the meantime.
--
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:
Hi Weize,
Since this seems be a support question, I suggest you ask it either on
https://stackoverflow.com/ or on the Python users' mailing-list
https://mail.python.org/mailman/listinfo/python-list
--
nosy: +
Antoine Pitrou <pit...@free.fr> added the comment:
I think the documentation is now clearer. Closing!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset 4aa84e728565a15a82727b9b971126e355f47e9d by Antoine Pitrou (Miss
Islington (bot)) in branch '3.6':
bpo-32306: Clarify c.f.Executor.map() documentation (GH-4947) (#4948)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
New changeset a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d by Antoine Pitrou in
branch 'master':
bpo-32306: Clarify c.f.Executor.map() documentation (#4947)
https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24
Antoine Pitrou <pit...@free.fr> added the comment:
I don't think so. It's good to have fortify enabled, especially in debug mode
:-)
If the warnings are harmless and there isn't an easy way to suppress them, then
I'm ok to close this
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +serhiy.storchaka
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32388>
___
_
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +4839
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +4836
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +njs
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32388>
___
___
Python
New submission from Antoine Pitrou <pit...@free.fr>:
See original discussion on python-dev:
https://mail.python.org/pipermail/python-dev/2017-December/151328.html
Summary: binary compatibility for C extensions which don't use the stable ABI
is currently "best effort" and us
Antoine Pitrou <pit...@free.fr> added the comment:
If I'm understanding correctly, the ".pyd" extension is hardcoded in the
various ".vcxproj" files. Which means this PR would need the help of a Windows
expert to progress forward :-S
--
Antoine Pitrou <pit...@free.fr> added the comment:
Actually, let me correct this: the build fails on Windows (see AppVeyor).
That's because the Windows build process, for some reason, produces untagged
pyd files.
--
___
Python tracke
Antoine Pitrou <pit...@free.fr> added the comment:
Yes... The patch itself is not very complex, but you have to dive into the
intricacies of typeobject.c to understand it :-/
--
___
Python tracker <rep...@bugs.python.org>
<https://
Antoine Pitrou <pit...@free.fr> added the comment:
Interestingly, the test suite doesn't seem affected at all.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +njs
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32387>
___
___
Python
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +4835
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Antoine Pitrou <pit...@free.fr>:
Windows and the major POSIX platforms (including Linux and macOS) now support
loading C extension with a version-tagged name (and build them likewise), such
as "foobar.cpython-36.so".
Following the discussion in
https:/
New submission from Antoine Pitrou <pit...@free.fr>:
The configure scripts has the following comment:
"""Use dynload_next.c only on 10.2 and below, which don't have native
dlopen()"""
It seems dynload_next.c can be removed now.
--
mess
Antoine Pitrou <pit...@free.fr> added the comment:
Updated benchmarks against git master (and using pyperf):
- before:
$ ./env-orig/bin/pyperf timeit -q "class Test: pass"
Mean +- std dev: 8.89 us +- 0.09 us
$ ./env-orig/bin/pyperf timeit -q -s "from logging import Logger
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 1f1a34c3145781628e10534440017b3b43211a60 by Antoine Pitrou in
branch 'master':
bpo-32379: Faster MRO computation for single inheritance (#4932)
https://github.com/python/cpython/commit/1f1a34c3145781628e10534440017b3b43
Antoine Pitrou <pit...@free.fr> added the comment:
Benchmarks with a parent:
* Before:
$ ./env-orig/bin/pyperf timeit -s "from unittest import TestCase" "class
Test(TestCase): pass"
.
Mean +- std dev: 10.4 us +- 0.1 us
* After:
$ ./env/bin/pyper
Antoine Pitrou <pit...@free.fr> added the comment:
Wow. That's a heavy price to pay indeed.
Unfortunately I'm not competent on IPv6. I'm cc-ing other core developers so
that they may chime in.
--
nosy: +gregory.p.smith, neologix, ysel
Antoine Pitrou <pit...@free.fr> added the comment:
I see. So the problem you are pointing out is that the tasks *arguments* are
consumed eagerly. I agree that may be a problem in some cases, though I think
in most cases people are concerned with the *results*.
Antoine Pitrou <pit...@free.fr> added the comment:
I think the difference here is that Python calls ferror() to tell whether an
error occurred on the underlying FILE*. Can you adapt your C program to check
ferror()?
--
___
Python tracke
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 776407fe893fd42972c7e3f71423d9d86741d07c by Antoine Pitrou
(Marcel Plch) in branch 'master':
bpo-31901: atexit callbacks should be run at subinterpreter shutdown (#4611)
https://github.com/python/cpython/
Antoine Pitrou <pit...@free.fr> added the comment:
By the way, Windows nowadays has inet_pton():
https://msdn.microsoft.com/en-us/library/windows/desktop/cc805844(v=vs.85).aspx
Are there other platforms without it? inet_pton() is part of POSIX.
--
nosy: +paul.moore, steve
Antoine Pitrou <pit...@free.fr> added the comment:
> There is no platform-compatible way to detect if a string is an IP address.
Actually, you could use the ipaddress module.
--
nosy: +pitrou
___
Python tracker <rep...@bugs.python
Antoine Pitrou <pit...@free.fr> added the comment:
Here is the command line:
gcc -pthread -c -Wno-unused-result -Wsign-compare -g -Og -Wall
-Wstrict-prototypes-std=c99 -Wextra -Wno-unused-result
-Wno-unused-parameter -Wno-missing-field-initializers
-Werror=implicit-function-decla
Antoine Pitrou <pit...@free.fr> added the comment:
I agree with the suggested fix. Do you want to submit a PR?
--
nosy: +pitrou -llecaroz
stage: -> needs patch
versions: +Python 3.6 -Python 3.5, Python 3.8
___
Python tracker <rep...@bug
Antoine Pitrou <pit...@free.fr> added the comment:
Python 2 doesn't call write(), it calls fwrite() and friends (i.e. it uses the
libc's buffered I/O API). Also we don't do anything special if the printed
string has a newline in it. So my guess is that it's a bug in th
Antoine Pitrou <pit...@free.fr> added the comment:
You may switch to multiprocessing.Pool (with the "forkserver" method).
Otherwise, you could workaround it by executing a function on all workers that
will reset the signal configuration. To maximize the chances that it do
Antoine Pitrou <pit...@free.fr> added the comment:
Benchmarks:
* before:
$ ./env-orig/bin/pyperf timeit "class Test: pass"
.
Mean +- std dev: 9.51 us +- 0.17 us
* after:
$ ./env/bin/pyperf timeit "class Test: pass"
.
Mean +- s
Change by Antoine Pitrou <pit...@free.fr>:
--
keywords: +patch
pull_requests: +4825
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
Change by Antoine Pitrou <pit...@free.fr>:
--
nosy: +inada.naoki, serhiy.storchaka, vstinner
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Antoine Pitrou <pit...@free.fr>:
MRO computation involves a complicated merge calculation over several lists.
But, for the simple (common) case where a class has a single base, the
computation could be much simpler: take the base's MRO and prepend the derived
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 dc5770b161a5e28eeff73a406cd4eddb0676c5b5 by Antoine Pitrou (Miss
Islington (bot)) in branch '3.6':
bpo-32377: improve __del__ docs and fix mention about resurrection (GH-4927)
(#4929)
https://github.com/python/cpython/
901 - 1000 of 16564 matches
Mail list logo
