Use _Py_EnterRecursiveCall private API in _bisectmodule.c

Feature or enhancement

I just noticed the _bisectmodule.c is the only internal module using the Py_EnterRecursiveCall and Py_LeaveRecursiveCall public API functions instead of the private ones with underscores. For both consistency and a tiny performance enhancement, I think it would make sense to use the private API instead.

Pitch

I have a PR ready for this, but since I have no idea of what I am doing this might be completely bogus 😉.

Linked PRs

gh-101903: use _Py_EnterRecursiveCall internal API in _bisectmodule.c #101931
gh-101903: Remove unnecessary undefs for non-existent/old macros Py_EnterRecursiveCall and Py_LeaveRecursiveCall #101923

@gdementen

Looks like the Public API functions

cpython/Python/ceval.c

Lines 3066 to 3081 in 23751ed

    
           /* Implement Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() as functions 
        
              for the limited API. */ 
        
           #undef Py_EnterRecursiveCall 
        
           int Py_EnterRecursiveCall(const char *where) 
        
           { 
        
               return _Py_EnterRecursiveCall(where); 
        
           } 
        
           #undef Py_LeaveRecursiveCall 
        
           void Py_LeaveRecursiveCall(void) 
        
           { 
        
               _Py_LeaveRecursiveCall(); 
        
           }

are just wrappers for the private static inline functions

cpython/Include/internal/pycore_ceval.h

Lines 135 to 147 in 7644935

    
           static inline int _Py_EnterRecursiveCall(const char *where) { 
        
               PyThreadState *tstate = _PyThreadState_GET(); 
        
               return _Py_EnterRecursiveCallTstate(tstate, where); 
        
           } 
        
           static inline void _Py_LeaveRecursiveCallTstate(PyThreadState *tstate)  { 
        
               tstate->c_recursion_remaining++; 
        
           } 
        
           static inline void _Py_LeaveRecursiveCall(void)  { 
        
               PyThreadState *tstate = _PyThreadState_GET(); 
        
               _Py_LeaveRecursiveCallTstate(tstate); 
        
           }

@gdementen - I don't see the harm in submitting a PR!

gh-101903: Remove obsolete undefs for previously removed macros Py_En…

As noted in #101931 (comment), this requires defining _bisectmodule.c as a core module, which IMO requires a broader discussion.

We deliberately make some stdlib extension modules use the public C API. As an (unrwritten) general rule, the modules in Modules/Setup.bootstrap.in are built using the internal C API, whereas the modules in Modules/Setup.stdlib.in should preferably use the public C API.

Suggesting to close this issue as not-planned.

See also Eric's comments from similar API issues: #31376 (comment) and #31376 (comment)

@erlend-aasland

Thanks @erlend-aasland

Merge branch 'main' into lockfreecp

pythongh-101903: Remove obsolete undefs for previously removed macros…

Navigation Menu

Repository navigation

Use _Py_EnterRecursiveCall private API in _bisectmodule.c #101903

Feature or enhancement

Pitch

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	/* Implement Py_EnterRecursiveCall() and Py_LeaveRecursiveCall() as functions
	for the limited API. */

	#undef Py_EnterRecursiveCall

	int Py_EnterRecursiveCall(const char *where)
	{
	return _Py_EnterRecursiveCall(where);
	}

	#undef Py_LeaveRecursiveCall

	void Py_LeaveRecursiveCall(void)
	{
	_Py_LeaveRecursiveCall();
	}

	static inline int _Py_EnterRecursiveCall(const char *where) {
	PyThreadState *tstate = _PyThreadState_GET();
	return _Py_EnterRecursiveCallTstate(tstate, where);
	}

	static inline void _Py_LeaveRecursiveCallTstate(PyThreadState *tstate) {
	tstate->c_recursion_remaining++;
	}

	static inline void _Py_LeaveRecursiveCall(void) {
	PyThreadState *tstate = _PyThreadState_GET();
	_Py_LeaveRecursiveCallTstate(tstate);
	}

Use _Py_EnterRecursiveCall private API in _bisectmodule.c #101903

Description

Feature or enhancement

Pitch

Linked PRs

Activity

OTheDev commented on Feb 14, 2023

erlend-aasland commented on Feb 21, 2023

erlend-aasland commented on Feb 21, 2023

OTheDev commented on Feb 21, 2023

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions