Comments (4)
FWIW, I'm hesitant to make immortal objects more prominent in the docs. Presently they are an internal implementation detail (which daring users may use at their own risk). If anything, I'd rather they were less prominent in the docs. The only reason to mention them in the docs at all is for the benefit of people that notice objects with a really big refcount (which always stays the same).
All that would change, of course, if we were to expose immortal objects via public API--which PEP 683 purposefully did not do (other than the slight change in semantics for a few refcount operations). However, I'm not sure the existing internal API should ever be made public. It would be a genuine foot gun in its current unconstrained and unmanaged form, inviting substantial memory leaks. At best we might eventually choose to expose some more-carefully-crafted variant that's either better constrained in scope, less generic, or better managed by the runtime (or all of those). Until then, I think we should avoid drawing people's attention to the concept/term.
from cpython.
It's mainly conceptual documentation that I was suggesting would be helpful, rather than getting into the exact mechanics.
At the very least, a glossary entry for other documentation like https://docs.python.org/3/library/sys.html#sys.getrefcount and https://docs.python.org/3/glossary.html#term-reference-count to point to rather than each mention having to provide its own short definition.
I don't think the actual definition needs to be particularly in depth, just give a bit more info about why immortal objects are a thing:
immortal object
To reduce runtime overhead (especially in free-threaded builds and when sharing objects between
subinterpreters), the CPython interpreter internally marks some objects (such as :const:`None`,
:const:`True`, and :const:`False`) as "immortal", and excludes them from the interpreter's normal
reference count tracking. This provides several practical benefits (as described in :pep:`683`) but
also means the immortal objects do not report accurate reference count information at runtime.
.. impl-detail::
Interpreters other than CPython may not need or define immortal objects.
And then tweak the "historical document" notice on the PEP to make it clear that while it may no longer be an accurate description of the technical implementation details, it will indefinitely provide an accurate description of the benefits of including immortal objects in the CPython implementation.
from cpython.
I'm in favor of this definition, but would say "may not report" instead of "does not report".
from cpython.
I agree with @ericsnowcurrently's proposal of keeping this mostly as an implementation detail since that was the original intent of the PEP. At the same time, @ncoghlan is very explicitly stating that it's an implementation detail so I wouldn't be opposed to that. I'll leave it to Eric to ultimately decide
from cpython.
Related Issues (20)
- Avoid TSan reported race in `run_udp_echo_server`
- Move opcode magic number out of `Lib/importlib/_bootstrap_external.py` HOT 1
- `test_warnings` fails if run with `-Werror` HOT 2
- Should `__rpow__()` take `modulo` argument? HOT 3
- Usage of `TestCase(object)` is prior to its definition
- test_types Leaks References When Channels or Queues Used
- Race condition in `make_pending_calls` in free-threaded build
- Repeated string concatenation much slower starting with Python 3.11 HOT 2
- Dictionary watchers deliver `added` event before it's guaranteed to be successful leading to possible incosistent state
- Add details for pickle serialization errors
- python3.12 _xxsubinterpreter behavior regression HOT 2
- Support for @auto decorator. HOT 1
- [Argument Clinic] Change the errors raised by the `path_t` converter HOT 6
- Missing decref in error handling of `func_get_annotation_dict`
- Accuracy issues of sum() specialization for floats/complexes HOT 5
- REPL auto-indentation is wrong with comments HOT 1
- Improve error message for unbalanced unpacking HOT 6
- Asyncio loop.sock_sendall() fails on Windows when sockets are shared across threads HOT 4
- Move detection of writes and shadowing of __debug__ from compiler to symtable.
- Instrumentation assertion failure when calling the registered handler explicitly HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from cpython.