On Mon, Aug 15, 2011 at 3:43 PM, Barry Warsaw <ba...@python.org> wrote: > 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.
I dunno; if it *didn't* do an INCREF it would be a pretty pointless macro (just expanding to "return x") and I like reducing the clutter of a very common idiom. So I favor #2. -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
