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 — Code objects, function objects and generator object contain quite a lot of redundant information · Issue #100719 · python/cpython

Code objects, function objects and generator object contain quite a lot of redundant information #100719

New issue
Copy link
New issue
Copy link
Closed
Closed
Code objects, function objects and generator object contain quite a lot of redundant information#100719
Copy link
Labels
performancePerformance or resource usagePerformance or resource usage

Description

@markshannon
markshannon
opened on Jan 3, 2023
Issue body actions

There is a quite a lot of redundancy in code, function and generator objects.

Intra-object redundancy

  1. Code objects have four fields ,co_nlocalsplus, co_nplaincellvars, co_nlocals, co_nfreevars. Any of these fields can be computed from the other three.
  2. Code objects have a qualified name and a name. The name is always the suffix of the qualified name. Changing this to qualifying prefix and name would save space and allow sharing.
  3. The defaults and keyword defaults for a function are separate and the keyword defaults are a dict. They could be combined into a single array.
  4. Generator objects have a gi_code field, which is redundant, as the frame contains a reference to the code object.

Inter-object redundancy

  1. Functions and generators have qualified name and name fields, which are almost always the same as the underlying code object. These should be lazily initialized

Linked PRs

  • GH-100719: Remove the co_nplaincellvars field from code objects. #100721
  • GH-100719: Remove redundant gi_code field from generator object. #100749

Activity

  1. markshannon
    added
    performancePerformance or resource usagePerformance or resource usage
    on Jan 3, 2023
  2. stevendaprano commented on Jan 4, 2023

    @stevendaprano
    stevendaprano
    on Jan 4, 2023
    Member
    More actions

    I have no opinion on whether these changes are good or bad, but they are surely breaking changes. Code objects aren't well documented, but they're not private implementation details. How do you plan to manage these changes?

  3. markshannon commented on Jan 4, 2023

    @markshannon
    markshannon
    on Jan 4, 2023
    MemberAuthor
    More actions

    The PyCodeObject struct is in the Include/cpython folder. So while it is not entirely private, we are allowed to change it.

  4. markshannon
    added a commit that references this issue on Jan 4, 2023

    GH-100719: Remove the `co_nplaincellvars` field from code objects. (G…

    15aecf8
  5. markshannon
    added a commit that references this issue on Feb 23, 2023

    GH-100719: Remove redundant `gi_code` field from generator object. (G…

    22b8d77
  6. markshannon
    closed this as completedon Mar 13, 2023
  7. terryjreedy commented on Mar 13, 2023

    @terryjreedy
    terryjreedy
    on Mar 13, 2023
    Member
    More actions

    @stevendaprano The python-level doc for 'internal types', including code objects, https://docs.python.org/3/reference/datamodel.html#codeobject says

    Their definitions may change with future versions of the interpreter, but they are mentioned here for completeness.

    'co_nplaincellvars' is not even mentioned in the 3.11 docs.

    generator objects are not listed here and their internal gi_xxx methods, as opposed to __next__, send, and throw, are not indexed.

  8. JelleZijlstra
    added a commit that references this issue on Sep 10, 2024

    pythonGH-100719: Remove redundant `gi_code` field from generator obje…

    9c3b43f
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

    performancePerformance or resource usagePerformance or resource usage

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      You are visitor 01402520 — 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.