Change by Jeremy Kloth :
--
pull_requests: +30420
pull_request: https://github.com/python/cpython/pull/32382
___
Python tracker
<https://bugs.python.org/issue46
Change by Jeremy Kloth :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeremy Kloth :
--
pull_requests: +30400
pull_request: https://github.com/python/cpython/pull/32347
___
Python tracker
<https://bugs.python.org/issue47
Change by Jeremy Kloth :
--
pull_requests: +30399
pull_request: https://github.com/python/cpython/pull/32346
___
Python tracker
<https://bugs.python.org/issue47
Jeremy Kloth added the comment:
It seems so, as the zlib update was also backported to 3.9 and 3.10.
--
___
Python tracker
<https://bugs.python.org/issue47
Jeremy Kloth added the comment:
My PR-32338 further reduces the runtime of the test another ~25%.
On my machine, before 85s, after 65s.
--
___
Python tracker
<https://bugs.python.org/issue46
Change by Jeremy Kloth :
--
nosy: +jkloth
nosy_count: 3.0 -> 4.0
pull_requests: +30394
pull_request: https://github.com/python/cpython/pull/32338
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30393
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32337
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
The latest zlib (1.2.12) introduces 3 new compiler warnings. Now being an
external library, I do not think we generally patch them, so I propose to
simply silence the warnings for the offending file.
For reference, the problem comes from
Change by Jeremy Kloth :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue45354>
___
___
Python-bugs-list
Change by Jeremy Kloth :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Pyth
Jeremy Kloth added the comment:
Resolved with merged PR.
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Python-
Jeremy Kloth added the comment:
Well, to really see where things are going wrong, there is always the verbose
option when launching Python:
py -v -c "import binascii"
This will output a lot of information but should help pin down what is exactly
being imported when the er
Jeremy Kloth added the comment:
This error will occur when there is a 64-bit/32-bit conflict. Normally, Python
extension modules are installed in architecture dependent locations, however
user-installed modules (pip install) can share a path referred to as "user
site".
A quick
Jeremy Kloth added the comment:
bpo-47089 is a duplicate of this issue and is fixed. This issue should be
closed as well.
--
___
Python tracker
<https://bugs.python.org/issue37
Change by Jeremy Kloth :
--
pull_requests: +30311
pull_request: https://github.com/python/cpython/pull/32240
___
Python tracker
<https://bugs.python.org/issue47
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue47089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +vstinner
type: -> performance
___
Python tracker
<https://bugs.python.org/issue47131>
___
___
Python-bugs-list mai
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30212
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32132
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
The string building and comparing of ast.dump() causes significant slowdowns on
the large ASTs produced when doing the roundtrip test on the stdlib.
This PR avoids that cost by doing a direct node traversal and comparison. It
results in a 33% runtime
Change by Jeremy Kloth :
--
pull_requests: +30168
pull_request: https://github.com/python/cpython/pull/32081
___
Python tracker
<https://bugs.python.org/issue46
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30167
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32079
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
pull_requests: +30146
pull_request: https://github.com/python/cpython/pull/32048
___
Python tracker
<https://bugs.python.org/issue44
Jeremy Kloth added the comment:
Backports state that they are ready... I'm just a little uneasy as I've never
used cherry_picker before. 3.10 went smooth, but 3.9 required manual merging.
--
___
Python tracker
<https://bugs.python.
Change by Jeremy Kloth :
--
pull_requests: +30139
pull_request: https://github.com/python/cpython/pull/32050
___
Python tracker
<https://bugs.python.org/issue44
Jeremy Kloth added the comment:
With 3.8 so close to security only, I would doubt it is worth it anymore. I've
just run the PR against HEAD and it still works as is, so should be good to go.
--
versions: -Python 3.8
___
Python tracker
<ht
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30127
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32037
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
Testing on Windows occasionally has issues in test_compileall when running with
multiple processes. This is due to other test files importing stdlib modules
at the same time that compileall is doing its own testing. While not fatal
(test_compileall
Jeremy Kloth added the comment:
OK, I know it has been a busy month for Python, but this issue is really
hampering my bug fixing efforts. It makes the complete regrtest useless for
me. I am required to run each affected test directly so it is possible to miss
side-effects of changes made
Change by Jeremy Kloth :
--
pull_requests: -30123
___
Python tracker
<https://bugs.python.org/issue46084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
pull_requests: +30123
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/issue46
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +30122
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/issu
Change by Jeremy Kloth :
--
pull_requests: -30121
___
Python tracker
<https://bugs.python.org/issue46084>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
keywords: +patch
nosy: +jkloth
nosy_count: 7.0 -> 8.0
pull_requests: +30121
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/32032
___
Python tracker
<https://bugs.python.org/i
New submission from Jeremy Kloth :
The newly implemented statically allocated Unicode objects do not clear their
cached representations (wstr and utf-8) at exit causing leaked blocks at exit
(see also issue46857).
At issue are the Unicode objects created by deepfreeze and the 1-character
Jeremy Kloth added the comment:
Did you also modify initconfig.c? That part is required as the usual
processing of the environment variable PYTHONDUMPREFS needed to enable
tracing output is ignored with -I
--
___
Python tracker
<ht
Jeremy Kloth added the comment:
> ./configure --enabled-shared --with-py-debug --with-trace-refs
(that's what I get for typing from memory):
./configure --enable-shared --with-pydebug --with-trace-refs
> > I proposed GH-31594 to fix this macro.
>
> Even using that chang
Jeremy Kloth added the comment:
> Oh wow. How did you find this leak? Did you read all C files and check for
> code specific to Windows? How did you proceed? Well spotted!
Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
initial inc (ob_refcnt == 1) and
Jeremy Kloth added the comment:
Note that an allocated block is still leaking.
Strange as well, when using dump_refs, the total refs are much more negative
(-12 linux, -13 Windows)
--
___
Python tracker
<https://bugs.python.org/issue46
Jeremy Kloth added the comment:
Good news, the difference on Windows was easy enough to find, bad news total
refs are now negative!
--- a/Objects/exceptions.c
+++ b/Objects/exceptions.c
@@ -3647,8 +3647,7 @@ _PyBuiltins_AddExceptions(PyObject *bltinmod)
#define INIT_ALIAS(NAME, TYPE
Jeremy Kloth added the comment:
> Would it be possible to create a download cache somewhere outside the Python
> source tree, so "git clean -fdx" would not remove this cache?
I was thinking of locating it next to the checkout directory. The
current structure is:
[worker r
Jeremy Kloth added the comment:
I personally would like to see caching restored so as to keep the duration of
buildbot runs as low as possible. The repeated fetching effectively doubles
compilation time for my Win11 builder.
--
___
Python
Jeremy Kloth added the comment:
Oh, I forgot to add that I'm in favor of following the threading.py behavior of
allowing <=0 to mean "non-blocking" (i.e., just check). This would probably
also benefit from a documentation upda
Change by Jeremy Kloth :
--
nosy: +eryksun, vstinner
___
Python tracker
<https://bugs.python.org/issue46790>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
As a follow on to bpo-46716, the various timeout parameters currently deal with
negative values differently in POSIX and Windows.
On POSIX, a negative value is treated the same as 0; check completion and raise
TimeoutExpired is still running.
On Windows
Change by Jeremy Kloth :
--
nosy: +pablogsal, vstinner
___
Python tracker
<https://bugs.python.org/issue46789>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
A recent change to the buildmaster config effectively disabled the caching of
the externals for Windows buildbots:
https://github.com/python/buildmaster-config/pull/255
If the caching is desired, a simple change to the buildmaster config is needed
Change by Jeremy Kloth :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue46788>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Jeremy Kloth :
When attempting to run the test harness, I receive the following:
Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File "C:\Public\Devel\cpython\main\Lib\test\__main__.
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +29535
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31390
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
While the current build does enable building of projects in parallel
(msbuild -m), the compilation of each project's source files is done
sequentially. For large projects like pythoncore or _freeze_module this can
take quite some time.
This simple PR
Jeremy Kloth added the comment:
> > the fix should be as simple as coercing the timeout values to >= 0.
>
> Popen._remaining_time() should return max(endtime - _time(), 0).
That was my first initial instinct as well, however, that change would
also affect more of the Popen be
Jeremy Kloth added the comment:
I've been able locally to reproduce the test_subprocess hang. The responsible
function is subprocess.run(). The test case, test_timeout(), uses a small
timeout value (0.0001), which, when given enough load, can cause the run() call
to hang.
A judicious use
Jeremy Kloth added the comment:
The test only completed once I purposefully terminated the offending Python
process. The only identifying information I noticed was the command-line of
`-c "while True: pass"`, indicating it was stuck in either
test_call_timeout() or te
New submission from Jeremy :
A source of one or more backslash-escaped newlines, and one final newline, is
not tokenized the same as a source where those lines are "manually joined".
The source
```
\
\
\
```
produces the tokens NEWLINE, ENDMARKER when piped to the tokenize module
Jeremy added the comment:
Wow, this was a fast turnaround! I was going to spin some cycles on this, but
would have not seen the solution in 50m.
--
___
Python tracker
<https://bugs.python.org/issue46
New submission from Jeremy :
At some point in 3.9 Python appears to have stopped accepting source that
starts with an indent, then a '\', then the indented statement. From the
lexical analysis [1] "Indentation cannot be split over multiple physical lines
using backslashes; the whitespa
Jeremy Kloth added the comment:
I'll note that it also fails on first run on the Windows 11 builder:
https://buildbot.python.org/all/#/builders/737/builds/65
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue45806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy added the comment:
> How common do you expect such errors to be though? Do you expect them to be
> more or less common than with os.chdir()? Do you expect the mitigations to
> be any different than with a failing os.chdir()?
It has come up for me with some frequency. But
Jeremy added the comment:
A LBYL won't always raise errors early as you point out. It will give earlier
warnings for a lot of cases, but makes contextlib.chdir usable in less places
than os.chdir.
Some return paths will always be errors, and some will be technically
recoverable but too
Change by Jeremy :
--
keywords: +patch
pull_requests: +27481
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/29218
___
Python tracker
<https://bugs.python.org/issu
Jeremy added the comment:
>If os.chdir is in os.supports_fd, the context manager can use dirfd =
>os.open(os.getcwd(), os.O_RDONLY). Using an fd should also work around the
>deleted directory case, though POSIX doesn't specify whether fchdir() succeeds
>in this case. It d
Jeremy added the comment:
Yes, precisely. Besides being an unreachable long abs path, it might have been
deleted since last visited. I’m working on a few more odd test cases.
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Jeremy :
The way that contextlib.chdir currently restores the old working directory, an
exception is raised if the program was already close to or beyond a system's
PATH_MAX. The context manager has no issue crafting the path in __enter__
because os.getcwd() can return
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +27062
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28712
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
Note that I have a pending PR for adding a Windows 11 build worker that will,
once merged, help in testing a solution.
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Jeremy Kloth :
It appears there have been some console related changes in Windows 11
==
ERROR: test_open_name (test.test_winconsoleio.WindowsConsoleIOTests
Jeremy Maitin-Shepard added the comment:
Yes, I would agree that the new APIs are a useful addition regardless of the
PyThread_exit_thread change.
As far as the proposed `Py_SetThreadExitCallback` that seems like a fine thing
for applications to use, as long as it doesn't impact how
Jeremy Maitin-Shepard added the comment:
To be clear, the problem I'm trying to address here is not specific to
embedding Python in a C++ application. In fact the issue came to my attention
while using Python directly, but loading an extension module that was written
in C++ using
Jeremy Maitin-Shepard added the comment:
In general, I view hanging threads as the least bad thing to do when faced with
either acquiring the GIL or not returning at all. There is a lot of existing
usage of Python that currently poses a risk of random crashes and memory
corruption while
Jeremy Maitin-Shepard added the comment:
I suppose calling `Py_Initialize`, `Py_FinalizeEx`, then `Py_Initialize` again,
then `Py_FinalizeEx` again in an embedding application, was already not
particularly well supported, since it would leak memory.
However, with this change it also leaks
Change by Jeremy Maitin-Shepard :
--
keywords: +patch
pull_requests: +26916
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28525
___
Python tracker
<https://bugs.python.org/issu
Jeremy Maitin-Shepard added the comment:
It looks like the `_thread` module does not actually expose
`PyThread_exit_thread` --- the similarly named `thread_PyThread_exit_thread`
just raises SystemExit.
>From a search in the codebase, it appears `PyThread_exit_thread` is currently
&g
Jeremy Maitin-Shepard added the comment:
Regarding your suggestion of banning daemon threads: I happened to come across
this bug not because of daemon threads but because of threads started by C++
code directly that call into Python APIs. The solution I am planning to
implement is to add
Jeremy Maitin-Shepard added the comment:
Regarding your suggestion of adding a hook like `Py_SetThreadExitCallback`, it
seems like there are 4 plausible behaviors that such a callback may implement:
1. Abort the process immediately with an error.
2. Exit immediately with the original exit
Jeremy Maitin-Shepard added the comment:
Another possible resolution would to simply make threads that attempt to
acquire the GIL after Python starts to finalize hang (i.e. sleep until the
process exits). Since the GIL can never be acquired again, this is in some
sense the simplest way
Jeremy Kloth added the comment:
Except that the output in question is not for manpages but for the
command-line. The analogous would be for `grep --help` (again an excerpt):
Context control:
-B, --before-context=NUM print NUM lines of leading context
-A, --after-context=NUM print NUM
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44779>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
There is a list `python-buildb...@python.org` that all buildbot owners have
been subscribed.
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44
New submission from Jeremy :
While writing a program using the multiprocessing library I stumbled upon what
appears to be a bug with how different platforms deal with private methods.
When a class has a private method which is the target for a multiprocessing
process, this name is correctly
Jeremy Kloth added the comment:
While now not as immediately beneficial, I believe that the linked PR would be
good for the long run. The ramifications of bpo-11105 meant that the Windows
buildbots were basically unusable for 5 days.
Realistically, any commit that triggers aborts
Change by Jeremy Kloth :
--
nosy: +jkloth
nosy_count: 11.0 -> 12.0
pull_requests: +25186
pull_request: https://github.com/python/cpython/pull/26578
___
Python tracker
<https://bugs.python.org/issu
Jeremy Kloth added the comment:
The PR has been successfully run on the buildbots.
Before:
https://buildbot.python.org/all/#/builders/593/builds/58
After:
https://buildbot.python.org/all/#/builders/593/builds/59
With these changes, at least now aborted runs can be seen as direct failures
Jeremy Kloth added the comment:
To verify the PR, can someone please add the test-with-buildbots label on GH?
--
___
Python tracker
<https://bugs.python.org/issue44
Change by Jeremy Kloth :
--
keywords: +patch
pull_requests: +25166
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26578
___
Python tracker
<https://bugs.python.org/issu
New submission from Jeremy Kloth :
Currently, a stack overflow is causing the debug build Windows buildbots to
abort (bpo-11105). Once the regrtest process is terminated, the buildbot test
process hangs indefinitely waiting for handles to be closed (see msg350191 from
bpo-37531 for some
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue44214>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Kloth added the comment:
Adding windows team to the nosy list
--
components: +Windows
nosy: +jkloth, paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<https://bugs.python.org/issue40
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue2889>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue37945>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue43538>
___
___
Python-bugs-list mailing list
Unsubscribe:
Jeremy Pinto added the comment:
In fact, the issue seems to be coming from open() itself when opening a
non-existent directory in write mode:
[nav] In [1]: import os
...: nonexixstent_dir = 'not_a_dir/'
...: assert not os.path.exists(nonexixstent_dir
New submission from Jeremy Pinto :
Issue: If you try to copy a file to a directory that doesn't exist using
shutil.copy, a IsADirectory error is raised saying the directory exists.
This issue is actually caused when `open(not_a_dir, 'wb') is called on a
non-existing dir.
Expected behaviour
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue43022>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
components: -Distutils
___
Python tracker
<https://bugs.python.org/issue42705>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue42802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Kloth :
--
nosy: +jkloth
___
Python tracker
<https://bugs.python.org/issue42611>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Jeremy Howard :
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Jeremy Howard :
--
keywords: +patch
pull_requests: +21988
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/23069
___
Python tracker
<https://bugs.python.org/issu
1 - 100 of 572 matches
Mail list logo
