On Aug 16, 2011, at 08:32 AM, Nick Coghlan wrote: >Indeed, this entire discussion was started by the extension of the >Py_RETURN_NONE idiom to also adopt Py_RETURN_NOTIMPLEMENTED. > >If the idiom is to be extended at all, why stop there? Why not cover >the Py_RETURN_TRUE and Py_RETURN_FALSE cases as well? > >Or, we can add exactly one new macro that covers all 3 cases, and >others besides. I haven't encountered any complaints about people >failing to understand the difference between "return Py_None;" and >"Py_RETURN_NONE;" and see no major reason why "return x;" vs >"Py_RETURN(x);" would be significantly more confusing. > >Based on this thread, there are actually two options I'd be fine with: >1. Just revert it and leave Py_RETURN_NONE as a special snowflake >2. Properly generalise the incref-and-return idiom via a Py_RETURN macro > >Incrementally increasing complexity by adding a second instance of the >dedicated macro approach is precisely what we *shouldn't* be doing.
My problem with Py_RETURN(x) is that it's not clear that it also does an incref, and without that, I think it's *more* confusing to use rather than just writing it out explicitly, Py_RETURN_NONE's historic existence notwithstanding. So I'd opt for #1, unless we can agree on a better color for the bikeshed. -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
