python / python/cpython

Make `test_c_subclass_of_heap_ctype_with_tpdealloc_decrefs_once` and `test_c_subclass_of_heap_ctype_with_del_modifying_dunder_class_only_decrefs_once` behavioral tests

Open
#127,881 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

tests type-refactor
Dominant language
Python
Stars
77.2k
Forks
35.9k
PR merge metrics
PR metrics pending

Description

Feature or enhancement

Proposal:

The test_c_subclass_of_heap_ctype_with_tpdealloc_decrefs_once and test_c_subclass_of_heap_ctype_with_del_modifying_dunder_class_only_decrefs_once tests were added to verify that we don't decref a type object too many times when destroying an instance of the type in certain scenarios. The tests currently verify this by checking reference counts. This is sensitive to implementation details and likely to break in the future. To make this more robust, we'd like to refactor the tests and supporting C code to verify that we don't crash (a symptom of decrefing too many times).

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Search for test_c_subclass_of_heap_ctype_with_tpdealloc_decrefs_once and test_c_subclass_of_heap_ctype_with_del_modifying_dunder_class_only_decrefs_once, then inspect the supporting C code used by those tests. Refactor the tests and C support so they verify that the scenarios do not crash rather than checking reference counts; run the affected tests to confirm this behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
c, python
Domain
testing
Issue type
Refactor
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.