On Mon, Aug 15, 2011 at 11:59 PM, Antoine Pitrou <[email protected]> wrote: > On Mon, 15 Aug 2011 09:49:43 -0400 > Barry Warsaw <[email protected]> wrote: >> I can see the small value in the convenience, but I tend to agree with >> Raymond >> here. I think we have to be careful about not descending into macro >> obfuscation world. > > How is Py_RETURN(Py_NotImplemented) more obfuscated than > Py_RETURN_NOTIMPLEMENTED ???
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. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
