On Wed, May 20, 2009 at 10:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote: > Jeffrey Yasskin <jyasskin <at> gmail.com> writes: >> >> Sorry, I didn't mean to get into a GIL debate. All I'm saying is that >> I don't think changing the definition of Py_INCREF and Py_DECREF >> justifies going to Python 4.0, so I don't think their definitions >> should be part of the ABI. If that's not what the ABI means, that's ok >> too. > > Consider, though, that if Py_INCREF and Py_DECREF are not part of the ABI, > enabling the ABI-specific preprocessor symbol will hide them, which might (or > might not!) annoy a lot of extension writers. Yes, that's my intention. (Well, not the annoying part, but making them use Py_IncRef instead for ABI compatibility is, I think, a good thing.) If they don't want ABI compatibility, they shouldn't ask for it. Giving them something else useful to ask for is why I mentioned an API compatibility mode. To decrease the annoyance of having to change source code, we could have Py_INCREF(x) expand to Py_IncRef(x) in ABI-compatibility mode.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4