I didn't say no use case exists, but rather "too special case." And/or shortcutting is great, but truthiness feels much more general than noneness to me.

But yes, 'first_non_none()" might have to address laziness in some manner, depending on the use case. Zero argument lambdas and expression quoting are the usual hacks (yes, both ugly in their own ways).

On Nov 29, 2017 12:14 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:
On 29 November 2017 at 16:13, David Mertz <mertz@gnosis.cx> wrote:
> Strong -1 still from me. Too special case for syntax. Just write a function
> 'first_non_none()' that can perfectly will handle the need.

That's the equivalent of SQL's COALESCE, and it's insufficient for the
same reason "and" and "or" are syntax rather than builtins: the
function form doesn't provide short-circuiting behaviour.

As far as utility goes, I put it in a similar category to matrix
multiplication: if you don't need it, you don't need it, but when you
do need it, you need it a *lot*.

The use case where these operations come up is when you're working
with partially structured hierarchical data (*cough*JSON*cough*). In
those kinds of structures, None is frequently used as a marker to say
"this entire subtree is missing", and you either want to propagate
that None, or else replace it with something else (and the "something
else" may be a network call to a different service, so you definitely
don't want to do it if you don't need to).

So I'd remind folks to try to avoid the "I don't need this, so nobody
needs this" mistake. It's OK to say "the use case exists, but I still
don't want that particular syntax for it in Python" (I'm personally
inclined to agree with you on that front). It's not OK to try to claim
there are no use cases where the status quo is awkward enough to
become irritating (since it's an empirically false statement that you
don't need to be making).


Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia