hexology is now known as hexology_
hexology_ is now known as hexology__
hexology__ is now known as hexology`
hexology` is now known as hexology_`
hexology_` is now known as hexology
<vstinner> Hodgestar: for the PEP 670, i asked the Steering Council to take a decision on it: https://github.com/python/steering-council/issues/90 "
<vstinner> Submission for SC consideration: PEP 670 -- Convert macros to functions in the Python C API"
<vstinner> Hodgestar: i didn't expect that i would be so complicated to get rid of macros :-p the PEP is much longer than what I expected
<Hodgestar> vstinner: I guess the long list of "these are the things that can go wrong with macros" is a useful reminder for the SC who probably aren't all thinking about such things day to day?
<vstinner> Hodgestar: the 2 main reasons against the PEP 670 are (1) fear of performance slowdown (2) "macro pitfalls" are fine, people learnt how to work around them
<vstinner> Hodgestar: for (1), I added benchmarks: no difference in a regular optimized build, 1.04% slower when inlining is disabled explicitly => IMO it's acceptable for a *debug* build
<vstinner> Hodgestar: for (2), well, i added many examples of real bugs reported by users
computerfarmer has joined #hpy
computerfarmer has quit [Remote host closed the connection]
computerfarmer has joined #hpy
computerfarmer has quit [Remote host closed the connection]
computerfarmer has joined #hpy
<Hodgestar> Re 2) -- one of the issues is that one has to remember which "functions" are really macros in order to avoid the pitfalls, and human brains are just bad at that. The same issue arises for borrowed or stolen references. Automated checks can help a bit, but well we've had code analysis tools for decades and there are still a seemingly endless number of bugs to be found.
<vstinner> Hodgestar: right :)
computerfarmer has quit [Remote host closed the connection]
computerfarmer has joined #hpy
computerfarmer has quit [Client Quit]
<vstinner> i wrote a PR modifying 25 macros to disallow using them as l-value, such as PyFloat_AS_DOUBLE() or PyList_GET_SIZE(): https://github.com/python/cpython/pull/28976
<vstinner> it seems controversial since it's technically an incompatible C API :-/
<vstinner> Hodgestar: oh no! it seems like i just wrote a PEP for that l-value change! :-D would you have time to have a quick look? https://github.com/vstinner/misc/blob/main/cpython/pep-lvalue.rst
<vstinner> especially at the HPy section :-)
dalley has joined #hpy
<Hodgestar> vstinner: Perhaps one can be a bit more explicit in the HPy section -- e.g. HPy could implement `HPy_SET_TYPE(ctx, obj, new_type)` but it's hard to see how we could implemented `HPy_TYPE(ctx, obj) = new_type`.
<Hodgestar> I think Py_SET_REFCNT is a completely crazy thing to expose as part of the API. I can see it being useful internally in CPython perhaps, but having some external code set a ref count seems just nuts.
<vstinner> Hodgestar: Py_SET_TYPE() is a legal of the past to workaround Windows linker issue when defining a type statically
<vstinner> Hodgestar: since HPy is designed for the future, it should not attempt to support legacy static types, and so it must not implement SET_TYPE()
<vstinner> Hodgestar: using Py_SET_REFCNT() smells really bad :) i hope that it's not used outside Python internals
<vstinner> Hodgestar: at least, it helps to detect code doing crazy things. it becomes possible to make this function ... a no-op :-)
<vstinner> Hodgestar: what about SET_SIZE? Cython uses it at some places
<vstinner> i published https://www.python.org/dev/peps/pep-0674/ Disallow using macros as l-value