Eric Snow added the comment:
You're welcome! Thanks for doing the work!
--
___
Python tracker
<https://bugs.python.org/issue45949>
___
___
Python-bugs-l
Change by Eric Snow :
--
pull_requests: +28315
pull_request: https://github.com/python/cpython/pull/30092
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
New changeset 121f1f893a39d0b58d3d2b5597505c154ecaac2a by Eric Snow in branch
'main':
bpo-45953: Statically initialize the small ints. (gh-30092)
https://github.com/python/cpython/commit/121f1f893a39d0b58d3d2b5597505c
Change by Eric Snow :
--
pull_requests: +28319
pull_request: https://github.com/python/cpython/pull/30096
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
(related: bpo-44059)
Presumably the problem relates to global state used in different interpreters
leading to an inconsistent state in the crashing extension (or its
dependencies).
@graysky, do you know if this was a problem before Python 3.8
Eric Snow added the comment:
It sounds like this bug is another case where we have made some objects
per-interpreter but others are still global and this is causing problems.
_PyUnicode_EqualToASCIIId() wouldn't have any problems if interpreters
weren't sharing any objects (or
Eric Snow added the comment:
FWIW, it makes sense to me for the interned strings to be per-interpreter
eventually.
Otherwise strings interned by an interpreter would persist after that
interpreter
is finalized, potentially leaking memory until the runtime is finalized.
However, if we end up
Change by Eric Snow :
--
pull_requests: +28350
pull_request: https://github.com/python/cpython/pull/30131
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
I've created a PR for moving the interned strings and identifiers to
_PyRuntimeState until we are ready to move them back to the interpreter.
--
___
Python tracker
<https://bugs.python.org/is
Eric Snow added the comment:
If that seems okay, I'll work on a backport PR for 3.10.
--
___
Python tracker
<https://bugs.python.org/issue46006>
___
___
Eric Snow added the comment:
+1 to splitting out the importlib.resources docs
I'm mostly +1 for splitting out the others (.abc, .machinery, .util) too, not
just .abc.
Regardless, a ToC at the top of the main page which identifies the submodules
(and provides a brief summary for each)
Eric Snow added the comment:
FWIW, one benefit to having everything in one doc (instead of one doc per
submodule) is that it's a little easier to see the bigger picture. This is
particularly important for folks interested in customizing the import system
(rather than just interacting
Eric Snow added the comment:
+1
--
___
Python tracker
<https://bugs.python.org/issue46109>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Eric Snow added the comment:
are there any objections to my PR?
--
___
Python tracker
<https://bugs.python.org/issue46006>
___
___
Python-bugs-list mailin
Eric Snow added the comment:
+1 on just reverting in both branches. I can deal with my stuff separately.
--
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
> IMO writing a complete rationale for running multiple interpreters in
> parallel which require a whole PEP.
FYI, I'm planning on having such a PEP published in the next few days.
--
___
Python trac
Eric Snow added the comment:
In summary, regarding the test_embed failure:
> FWIW: from test_embed.test_init_setpythonhome:
>
> if not config['executable']:
> config['use_frozen_modules'] = -1
>
> From the buildbot test stdout (but not pytho
Eric Snow added the comment:
Just to be clear, the test_embed failure is on AMD64 FreeBSD Non-Debug 3.x
(https://buildbot.python.org/all/#/builders/172).
I agree that 99fcf15052 (bpo-45582: Port getpath[p].c to Python (GH-29041)) is
likely to be the cause.
--
nosy: +steve.dower
Eric Snow added the comment:
A FreeBSD builder where it's working:
AMD64 FreeBSD Shared 3.x (koobs-freebsd-564d)
OS: FreeBSD 14.0-CURRENT main-n244626-cb7cc72c546: GENERIC-NODEBUG (amd64)
System: 2-core, 8Gb, VirtualBox (6.x) Guest Features: - Compiler: FreeBSD clang
version 11.0.1 (ll
Change by Eric Snow :
--
pull_requests: +28645
pull_request: https://github.com/python/cpython/pull/30438
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
I just put up a PR that should fix the failure.
--
___
Python tracker
<https://bugs.python.org/issue46263>
___
___
Python-bug
Eric Snow added the comment:
New changeset 68c76d9766cccb5fd992b0ac4b39645d9665dbe2 by Eric Snow in branch
'main':
bpo-46263: Do not ever expect "use_frozen_modules" to be -1. (gh-30438)
https://github.com/python/cpython/commit/68c76d9766cccb5fd992
Change by Eric Snow :
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issue46263>
___
___
Python-bugs-list mailing list
Unsubscrib
Eric Snow added the comment:
test_pyobject_freed_is_freed is still failing on AMD64 FreeBSD Shared 3.x.
--
stage: patch review ->
status: pending -> open
___
Python tracker
<https://bugs.python.org/i
Eric Snow added the comment:
Is this a duplicate of bpo-15751? (also see bpo-10915)
--
___
Python tracker
<https://bugs.python.org/issue46295>
___
___
Pytho
Eric Snow added the comment:
So sys.exception() will be equivalent to sys.exc_info()[1] (or rather,
sys.exc_info() will be (type(sys.exception()), sys.exception(),
sys.exception().__traceback__))?
That seems good to me.
--
nosy: +eric.snow
Eric Snow added the comment:
FWIW, here's an alternative we should *not* pursue: return just the exception
from sys.exc_info(). For compatibility, we would implement `__iter__` and
`__getitem__` on BaseException, to duplicate the behavior of the current tuple.
There are a number of
Eric Snow added the comment:
I'll look into this today. To reproduce, I should run the urllib3 test suite?
--
assignee: -> eric.snow
stage: -> needs patch
___
Python tracker
<https://bugs.python.
Eric Snow added the comment:
I must be missing something. Here is what I did:
```
$ cd cpython
$ git checkout main
$ make -j8
$ ./python -v venv ../venv-urllib3
$ cd ..
$ git clone https://github.com/urllib3/urllib3
$ cd urllib3
$ ../venv-urllib3/bin/python3 -m pip install nox
$ ../venv
Eric Snow added the comment:
It looks like the urllib3 CI is passing for 3.11.0a3:
https://github.com/urllib3/urllib3/runs/4762856431 (Ubuntu 3.11-dev test-3.11).
Is there a urllib3 issue number you could point me at?
--
___
Python tracker
Eric Snow added the comment:
Why not `PyAPI_FUNC(PyObject *) PyErr_GetActiveException(void);`?
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
New changeset cf496d657a1a82eaf9ebfb47d721676fef6effa5 by Eric Snow in branch
'main':
bpo-45953: Statically allocate and initialize global bytes objects. (gh-30096)
https://github.com/python/cpython/commit/cf496d657a1a82eaf9ebfb47d72167
Eric Snow added the comment:
> pip install -r dev-requirements.txt
> pip install ".[socks,secure,brotli]"
> pytest
I was able to reproduce the crash with these steps. Thanks!
--
___
Python tracker
<https://bugs
Eric Snow added the comment:
FYI, I get the crash with just:
pytest
test/contrib/test_pyopenssl.py::TestHTTPS::test_verify_none_and_bad_fingerprint
--
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
It looks like PyThreadState.async_exc is getting set to 0x01 somewhere. There
isn't any code like that in
https://github.com/python/cpython/commit/32a67246b0d1e08cd50fc3bfa58052cfeb515b2e.
However, the struct layout of PyThreadState did change slightly in
Eric Snow added the comment:
I'm glad we were able to figure it out relatively quickly...and without any big
headaches. :)
And thanks for testing against the alpha releases!!! You're having a positive
impact.
--
resolution: -&
New submission from Eric Snow :
Let's look at a hypothetical module "spam" and its submodule "spam.eggs":
```
# spam.py
import sys
sys.modules['spam.eggs'] = None
```
Then:
>>> import spam.eggs
>>> import sys
>>> sys.modules['
Eric Snow added the comment:
New changeset ed57b36c32e521162dbb97199e64a340d3bff827 by Eric Snow in branch
'main':
bpo-45953: Statically allocate the main interpreter (and initial thread state).
(gh-29883)
https://github.com/python/cpython/commit/ed57b36c32e521162dbb97199e64a3
Eric Snow added the comment:
> adding a new "gc" member in the _PyRuntimeState structure also causes the ABI
> CI check to fail.
What if you move it to the end of the struct?
--
___
Python tracker
<https://bugs.py
Eric Snow added the comment:
> (*) I made the GC state per-interpreter: commit
> 7247407c35330f3f6292f1d40606b7ba6afd5700 (Nov 20, 2019)
FYI, this was done by me in an earlier comment which we ended up
reverting. Later you basically un.reverted that.
> The bug is that a C functi
Eric Snow added the comment:
> I'm going to assume the "even though sys.modules has `None`" case,
> which I think is an oversight and should probably get fixed
Yep, I agree. That's the case I was looking at in the first place. I noticed
the other two as I wa
New submission from Eric Snow :
The static initializer for `_PyRuntime` is currently defined in
Include/internal/pycore_runtime.h. However, it is only needed by
Python/pylifecycle.c (and Python/pystate.c for an optimization) and should only
be used there. (Also, the initializer is quite
Change by Eric Snow :
--
keywords: +patch
pull_requests: +28785
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30587
___
Python tracker
<https://bugs.python.org/issu
Eric Snow added the comment:
New changeset bc02eac9d2cb36faffc5027b7ce09e6dd0922a7f by Eric Snow in branch
'main':
bpo-46370: Move the static initializer for _PyRuntime to its own header file.
(gh-30587)
https://github.com/python/cpython/commit/bc02eac9d2cb36faffc5027b7ce09e
Change by Eric Snow :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Eric Snow :
--
pull_requests: +28786
pull_request: https://github.com/python/cpython/pull/30588
___
Python tracker
<https://bugs.python.org/issue45
Change by Eric Snow :
--
pull_requests: +28787
pull_request: https://github.com/python/cpython/pull/30589
___
Python tracker
<https://bugs.python.org/issue45
Change by Eric Snow :
--
pull_requests: +28788
pull_request: https://github.com/python/cpython/pull/30590
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
New changeset 324908ba936d5d262026deebb81f050803848c41 by Eric Snow in branch
'main':
bpo-45953: Statically initialize all the PyThreadState fields we can. (gh-30590)
https://github.com/python/cpython/commit/324908ba936d5d262026deebb81f05
Eric Snow added the comment:
New changeset 322f962f3ee31d0dbde99e36379de8488ccc6804 by Eric Snow in branch
'main':
bpo-45953: Statically initialize all the non-object PyInterpreterState fields
we can. (gh-30589)
https://github.com/python/cpyt
Eric Snow added the comment:
> the deep-frozen objects also reference the small ints directly, as well as
> the singleton for b"".
> Is this even safe across Py_Finalize()/Py_Initialize()? If not, we'll need to
> roll that back as well.
The small ints and the e
New submission from Eric Snow :
`_Py_Identifier` has been useful but at this point there is a faster and
simpler approach we could take as a replacement: statically initialize the
objects as fields on `_PyRuntimeState` and reference them directly through a
macro.
This would involve the
Eric Snow added the comment:
## Background ##
`_Py_Identifier` (and `_Py_IDENTIFIER()`, etc.) was added in 2011 [1][2] for
several reasons:
* provide a consistent approach for a common optimization: caching C-string
based string objects
* facilitate freeing those objects during runtime
Change by Eric Snow :
--
keywords: +patch
pull_requests: +29120
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/30941
___
Python tracker
<https://bugs.python.org/issu
Eric Snow added the comment:
In addition to what Mark said, note that co_varnames get's populated lazily by
the Python-level getter for code.co_varnames. So could you call the Python
function before entering the hot path?
Regardless, a dedicated C-API for this like Mark suggested wou
Eric Snow added the comment:
New changeset 247480a21cb165efdacc346a2d589dfc27e18283 by Eric Snow in branch
'main':
bpo-46541: Generate the global objects initializer. (gh-30941)
https://github.com/python/cpython/commit/247480a21cb165efdacc346a2d589d
Eric Snow added the comment:
On Tue, Jan 25, 2022 at 4:14 PM STINNER Victor wrote:
> Currently, most CI run "make buildbottest" which uses -r option of
> libregrtest: randomize tests order.
How hard would it be to first randomize the list and then move the
slow tests up to a
Eric Snow added the comment:
> Any chance we could revert the recent renaming of tstate.exc_state and
> tstate.root_cframe
Yeah, I'll sort this out. Sorry for that.
--
___
Python tracker
<https://bugs.python.
Change by Eric Snow :
--
pull_requests: +29221
pull_request: https://github.com/python/cpython/pull/31038
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
If necessary, we can keep _Py_IDENTIFIER() (and the functions). Regardless, we
can stop using it internally.
--
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
FYI, I've posted to python-dev for feedback before proceeding:
https://mail.python.org/archives/list/python-...@python.org/thread/DNMZAMB4M6RVR76RDZMUK2WRLI6KAAYS/
--
___
Python tracker
<https://bugs.py
Eric Snow added the comment:
> I'm running some long-running (possibly infinite) tasks in the thread pool,
> and I cancel them in an `atexit` callback
To be clear, by "cancel" you are not talking about Future.cancel(). Rather,
your handler causes all running tasks to
Eric Snow added the comment:
> I'm running some long-running (possibly infinite) tasks in the thread pool,
> and I cancel them in an `atexit` callback
Alternately, perhaps ThreadPoolExecutor isn't the right fit here, as implied by
the route you ended up going. It seems li
Eric Snow added the comment:
FWIW, here's a brain dump about ThreadPoolExecutor and its atexit handler after
having looked at the code.
First, the relationship between the objects involved:
* work item -> Future
* work item -> task (e.g. function)
* queue -> [work
Eric Snow added the comment:
> This means that ThreadPoolExecutor's atexit runs before mine,
> and since I never get a chance to cancel my tasks, it deadlocks.
(assuming we want to support long-running tasks here)
With all the above in mind, there are a few things that may help.
Eric Snow added the comment:
(thanks Victor:
https://mail.python.org/archives/list/python-...@python.org/message/7RMLIJHUWVBZFV747TFEHOE6LNBVQSMM/)
3rd party use of _Py_IDENTIFIER():
* blender
+
https://github.com/blender/blender/blob/master/source/blender/python/intern/bpy_traceback.c
Change by Eric Snow :
--
pull_requests: +29389
pull_request: https://github.com/python/cpython/pull/31219
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
New changeset 1e6214dbd6a980b47123229aefd60bb2c9341b53 by Eric Snow in branch
'main':
bpo-45952: Get the C analyzer tool working again. (gh-31219)
https://github.com/python/cpython/commit/1e6214dbd6a980b47123229aefd60b
Change by Eric Snow :
--
pull_requests: +29390
pull_request: https://github.com/python/cpython/pull/31220
___
Python tracker
<https://bugs.python.org/issue45
Eric Snow added the comment:
New changeset c018d3037b5b62e6d48d5985d1a37b91762fbffb by Eric Snow in branch
'main':
bpo-45952: Get the C analyzer tool working again. (gh-31220)
https://github.com/python/cpython/commit/c018d3037b5b62e6d48d5985d1a37b
Eric Snow added the comment:
New changeset 81c72044a181dbbfbf689d7a977d0d99090f26a8 by Eric Snow in branch
'main':
bpo-46541: Replace core use of _Py_IDENTIFIER() with statically initialized
global objects. (gh-30928)
https://github.com/python/cpyt
Change by Eric Snow :
--
pull_requests: +29396
pull_request: https://github.com/python/cpython/pull/31225
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 77bab59c8a1f04922bb975cc4f11e5323d1d379d by Eric Snow in branch
'main':
bpo-36876: Update the c-analyzer whitelist. (gh-31225)
https://github.com/python/cpython/commit/77bab59c8a1f04922bb975cc4f11e5
Change by Eric Snow :
--
pull_requests: +29409
pull_request: https://github.com/python/cpython/pull/31239
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
@Eddie, what can I do to push this forward? FYI, in addition to the python-dev
thread a few weeks back, I've brought the matter up with the steering council.
[1]
Also, if we can get back to performance-neutral (currently at about 4% slower)
then there wou
Eric Snow added the comment:
New changeset cb68788dcadf43b47292bab7816a5ed9efa69730 by Eric Snow in branch
'main':
bpo-36876: Minor cleanup to c-analyzer "ignored" data.' (gh-31239)
https://github.com/python/cpython/commit/cb68788dcadf43b
Change by Eric Snow :
--
pull_requests: +29430
pull_request: https://github.com/python/cpython/pull/31264
___
Python tracker
<https://bugs.python.org/issue36
Eric Snow added the comment:
New changeset 80e4f262aa27a39abf3fadc19a6323fea4607a8f by Eric Snow in branch
'main':
bpo-36876: Make sure the c-analyzer is checking all the source files.'
(gh-31264)
https://github.com/python/cpython/commit/80e4f262aa27a39abf3fadc19
Eric Snow added the comment:
On Fri, Feb 11, 2022 at 1:36 AM Christoph Reiter wrote:
> Sorry if off topic, but I noticed that CPython doesn't deprecate macros in
> code, while with gcc/clang it's possible to show compiler warnings for them
> using some pragma magic:
&g
Eric Snow added the comment:
On Mon, Feb 14, 2022 at 2:28 AM Petr Viktorin wrote:
> Eric, is this necessary? Would an old-school `int` do?
> Or should we say it's 2022 already and everyone needs to use stdbool.hfore
> bools?
I started using ``bool`` (stdbool.h) when I saw i
Eric Snow added the comment:
With core code sorted out, stdlib and 3rd party extension modules are left to
sort out.
I see the following possibilities:
* leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
* change `_Py_IDENTIFIER()` to create static string objects (then
Change by Eric Snow :
--
Removed message: https://bugs.python.org/msg413241
___
Python tracker
<https://bugs.python.org/issue46541>
___
___
Python-bugs-list m
Eric Snow added the comment:
With core code sorted out, stdlib and 3rd party extension modules are left to
sort out.
I see the following possibilities:
1. leave `_Py_IDENTIFIER()` alone (it is already disallowed in core code)
2. change `_Py_IDENTIFIER()` to create static string objects
Change by Eric Snow :
--
pull_requests: +29494
pull_request: https://github.com/python/cpython/pull/31344
___
Python tracker
<https://bugs.python.org/issue46
New submission from Eric Snow :
Currently it is created dynamically from the tuple freelist.
--
assignee: eric.snow
components: Interpreter Core
messages: 413268
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Statically allocate and initialize
Eric Snow added the comment:
Also see bpo-45953.
--
___
Python tracker
<https://bugs.python.org/issue46753>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Eric Snow :
--
keywords: +patch
pull_requests: +29495
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31345
___
Python tracker
<https://bugs.python.org/issu
Change by Eric Snow :
--
pull_requests: +29496
pull_request: https://github.com/python/cpython/pull/31346
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
New changeset 12360aa159c42c7798fd14225d271e6fd84db7eb by Eric Snow in branch
'main':
bpo-46541: Discover the global strings. (gh-31346)
https://github.com/python/cpython/commit/12360aa159c42c7798fd14225d271e
Change by Eric Snow :
--
pull_requests: +29513
pull_request: https://github.com/python/cpython/pull/31363
___
Python tracker
<https://bugs.python.org/issue46
Change by Eric Snow :
--
pull_requests: +29514
pull_request: https://github.com/python/cpython/pull/31364
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
New changeset 6c8958948666403f2370ca7b4c0a52b2010ec16d by Eric Snow in branch
'main':
bpo-46541: Drop the check for orphaned global strings. (gh-31363)
https://github.com/python/cpython/commit/6c8958948666403f2370ca7b4c0a52
Eric Snow added the comment:
New changeset 4d8a515d193a4c9f3844704f974ddb870d7ee383 by Eric Snow in branch
'main':
bpo-46541: Scan Fewer Files in generate_global_objects.py (gh-31364)
https://github.com/python/cpython/commit/4d8a515d193a4c9f3844704f974ddb
New submission from Eric Snow :
This removes a number of static variables and is a little more efficient.
--
assignee: eric.snow
components: Interpreter Core
messages: 413313
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Replace Locally Cached
Change by Eric Snow :
--
keywords: +patch
pull_requests: +29516
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31366
___
Python tracker
<https://bugs.python.org/issu
New submission from Eric Snow :
The code generated by clinic.py is already partially statically initialized.
Currently we init the other fields in Python/getargs.c:parser_init(), which
runs the first time we try to use each parser. AFAICS, that remaining init
that could be done statically
New submission from Eric Snow :
We need this to statically initialize PyArg_Parser.kwtuple. (See bpo-46772.)
For now this will be a "private" API (leading underscore). Ultimately, we'll
want a Public API, so we can eventually stop exposing *any* objects as symbols
in the
Change by Eric Snow :
--
dependencies: +Add a Private API for Looking Up Global Objects, Statically
allocate and initialize the empty tuple.
___
Python tracker
<https://bugs.python.org/issue46
Eric Snow added the comment:
(from https://github.com/python/cpython/pull/31376#issuecomment-1041836106)
[corona10]
> Should we create the separate bpo issue if module changes are too noisy?
I think it's fine to use the one issue. There are only 26 modules with
`NEEDS_PY_IDENTIF
Change by Eric Snow :
--
nosy: +eric.snow
___
Python tracker
<https://bugs.python.org/issue43974>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 2629 matches
Mail list logo
