GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Allocating extra data after an object instance · Issue #103743 · python/cpython

Allocating extra data after an object instance #103743

New issue
Copy link
New issue
Copy link
Closed
Closed
Allocating extra data after an object instance#103743
Copy link
Labels
topic-C-APItype-featureA feature request or enhancementA feature request or enhancement

Description

@jbradaric
jbradaric
opened on Apr 24, 2023
Issue body actions

Feature or enhancement

Add an unstable (in PEP 689 sense) function that allocates memory for a GC object and allows the caller to specify the size of additional memory that should be allocated after the object. Similar to what could be done using _PyObject_GC_Malloc function in Python <= 3.10.

Pitch

Currently there is no way of allocating extra data after an object and still being able to have a standard Python class that supports GC, allows inheriting and doesn't come with limitations of PyVarObject (see #103740).

See the linked discussion for more details, but in essence the use case is the following. We have a base class and metaclass that support defining "slots" on classes (similar to Python __slots__, but with a different behavior, more on that later). The data for the slots is stored after the object, in the same block of memory. When inheriting from a class that defines such "slots", the subclass gets all the slots from its base classes + slots defined on it. The data for all those slots is always stored after the object, so the slot storage size doesn't really come into calculation for tp_basicsize.

A nice effect of this behavior is that a subclass can inherit from multiple classes with each of the bases defining its own slots. The subclass then gets all those slots, as if they were directly defined on it (in contrast with Python __slots__, which prevents such inheritance).

CC: @encukou

Previous discussion

See this discussion for more details.

Linked PRs

  • gh-103743: Add PyUnstable_Object_GC_NewWithExtraData #103744

Activity

  1. jbradaric
    added
    type-featureA feature request or enhancementA feature request or enhancement
    on Apr 24, 2023
  2. arhadthedev
    added
    topic-C-API
    on Apr 24, 2023
  3. jbradaric
    added 5 commits that reference this issue on Apr 24, 2023

    pythongh-103743: Add PyUnstable_Object_GC_NewWithExtraData (python#10…

    d300004

    pythongh-103743: Add PyUnstable_Object_GC_NewWithExtraData (python#10…

    8bf01ab

    pythongh-103743: Add PyUnstable_Object_GC_NewWithExtraData (python#10…

    aa3716f

    pythongh-103743: Add PyUnstable_Object_GC_NewWithExtraData (python#10…

    cc46476

    pythongh-103743: Add PyUnstable_Object_GC_NewWithExtraData (python#10…

    d644206
  4. encukou
    added a commit that references this issue on May 2, 2023

    gh-103743: Add PyUnstable_Object_GC_NewWithExtraData (GH-103744)

    87223f3
  5. encukou
    closed this as completedon May 2, 2023
  6. carljm
    added 2 commits that reference this issue on May 2, 2023

    Merge branch 'main' into inlinecomp2

    0727d6f

    Merge branch 'main' into cached_property_docs

    b9c39e3
  7. facebook-github-bot
    added a commit that references this issue on Aug 5, 2024

    Switch from using _PyObject_GC_Malloc to PyUnstable_Object_GC_NewWith…

    9a8300b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    topic-C-APItype-featureA feature request or enhancementA feature request or enhancement

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402503 — GeezerVison does not store the pages you look up.
      Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.