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 — Explain why the current state of the API is inconsistent · Issue #30 · capi-workgroup/api-evolution

Explain why the current state of the API is inconsistent #30

New issue
Copy link
New issue
Copy link
Open
Open
Explain why the current state of the API is inconsistent#30
Copy link

Description

@vstinner
vstinner
opened on Oct 14, 2023
Issue body actions

Example: in PR python/cpython#110848 Antoine is surprised that the PyThread_start_new_thread() function is part of the limited C API but is not documented.

We should explain that in the past, we didn't pay much attention to document and tests all limited C API functions, and that some functions were added to the limited C API by mistake. The limited c API was even "the default", before there was a clear cut between limited and non-limited, by creating Include/cpython/ sub-directory.

While the API can be inconsistent, it cannot be changed all sudden. We are not going to remove undocumented functions just because they are undocumented. Documentation can be written. Functions can be removed, but following PEP 387 deprecation process.

The only exception that I saw is when a function is part of the limited C API but cannot be used in the limited C API since it's broken: in that case, it can be removed immediately. I did that for the "trash can" API which was always broken. Same for PyWeakref_GET_OBJECT(): the implementation uses a member of structure whereas the structure is not part of the limited C API.

Activity

  1. vstinner
    added
    guidelineTo be included in guidelines PEPTo be included in guidelines PEP
    on Oct 14, 2023
  2. gvanrossum commented on Oct 14, 2023

    @gvanrossum
    gvanrossum
    on Oct 14, 2023
    Contributor
    More actions

    You can’t remove 100% broken functions from the Stable ABI though. Code may link with them but never call them, or handle an exception gracefully. Right?

    Reacted by Steve Dower and Petr Viktorin
  3. vstinner commented on Oct 14, 2023

    @vstinner
    vstinner
    on Oct 14, 2023
    ContributorAuthor
    More actions

    I don't think that we removed any stable ABI function so far, the functions only kept as "ABI only" just works. For immortal unicode, it's implemented by leaking memory (Py_INCREF) if i recall correctly. Maybe it could be modified to use immortal ref count now.

    I was only talking about the public C API and the limited API, so at the API level.

    Reacted by Guido van Rossum
  4. encukou commented on Oct 17, 2023

    @encukou
    encukou
    on Oct 17, 2023
    Contributor
    More actions

    The guideline label is for the PEP that will list guidelines for new API. The PEP should just say that API should be documented and tested: #31
    I'll remove the label from here.

  5. encukou
    removed
    guidelineTo be included in guidelines PEPTo be included in guidelines PEP
    on Oct 17, 2023
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

    No labels
    No labels

    Type

    No type

    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.