Strong -1 still from me. Too special case for syntax. Just write a function 'first_non_none()' that can perfectly will handle the need. On Nov 28, 2017 10:09 PM, "Steven D'Aprano" wrote:

On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote:

...

...

I also cc python-dev to see if anybody here is strongly in favor or

against this inclusion.

...

Put me down for a strong -1. The proposal would occasionally save a few keystokes but comes at the expense of giving Python a more Perlish look and a more arcane feel.

I think that's an unfair characterisation of the benefits of the PEP. It's not just "a few keystrokes".

Ironically, the equivalent in Perl is // which Python has used for truncating division since version 2.4 or so. So if we're in danger of looking "Perlish", that ship has sailed a long time ago.

Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two mature, well-known languages and two up-and-coming languages.

[...]

...

timeout ?? local_timeout ?? global_timeout

As opposed to the status quo:

timeout if timeout is not None else (local_timeout if local_timeout is not None else global_timeout)

Or shorter, but even harder to understand:

(global_timeout if local_timeout is None else local_timeout) if timeout is None else timeout

I'd much prefer to teach the version with ?? -- it has a simple explanation: "the first of the three given values which isn't None". The ?? itself needs to be memorized, but that's no different from any other operator. The first time I saw ** I was perplexed and couldn't imagine what it meaned.

Here ?? doesn't merely save a few keystrokes, it significantly reduces the length and complexity of the expression and entirely cuts out the duplication of names.

If you can teach

timeout or local_timeout or global_timeout

then you ought to be able to teach ??, as it is simpler: it only compares to None, and avoids needing to explain or justify Python's truthiness model.

...

'foo' in (None ?? ['foo', 'bar'])

If you can understand

'foo' in (False or ['foo', 'bar'])

then surely you can understand the version with ??.

...

requested_quantity ?? default_quantity * price

Again:

(default_quantity if requested_quantity is None else requested_quantity) * price

I'd much prefer to read, write and teach the version with ?? over the status quo.

-- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 29 November 2017 at 16:13, David Mertz 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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 29 November 2017 at 18:49, Kirill Balunov wrote:

2017-11-29 11:14 GMT+03:00 Nick Coghlan :

...

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).

If the problem with the proposed syntax, but there are cases for use, it may be worth to bikeshed one more time?

I don't think enough time has passed since we first discussed it. Since Guido has already said "not for 3.7", we can give folks another 12+ months to ponder the problem, and then maybe revisit it for 3.8. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

בתאריך יום ד׳, 29 בנוב׳ 2017, 11:46, מאת Steven D'Aprano ‏< steve@pearwood.info>:

On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:

...

29.11.17 08:08, Steven D'Aprano пише:

...

Perl is hardly the only language with null-coalescing operators -- we might better describe ?? as being familiar to C#, PHP, Swift and Dart. That's two mature, well-known languages and two up-and-coming languages.

What is the syntax of the ternary operator in these languages?

All four use:

condition ? first : second

for the ternary if operator.

This suggests something like "ifNone" keyword : x = a ifNone b ifNone c Elazar

בתאריך יום ד׳, 29 בנוב׳ 2017, 12:29, מאת Lele Gaifax ‏

:

Kirill Balunov writes:

...

Since the proposed semantics is more similar to the idea of "or", may be it is better to consider something like:

timeout then local_timeout then global_timeout

I do not know how much this is a frequent case to be worthy of a keyword.

That sounds awkward... what about

timeout else local_timeout else global_timeout

instead?

I think then and else can be ruled out since they can be very confusing when used in a conditinal statement or a comprehension. x = a if x else y else b # wait. what? Elazar

On 29 November 2017 at 21:53, Serhiy Storchaka wrote:

29.11.17 11:45, Steven D'Aprano пише:

...

On Wed, Nov 29, 2017 at 09:14:12AM +0200, Serhiy Storchaka wrote:

...

What is the syntax of the ternary operator in these languages?

All four use:

condition ? first : second

for the ternary if operator.

If all four use ?, it is natural that in operators which are shortcuts of the ternary operator they use ?. But in Python the bar of introducing ? is higher.

It's also noteworthy that they all offer "&&" and "||" as short circuiting "and" and "or" operators. When you have that pattern established, then "??" fits right in. With Python's only spelling for the logical operators being "and" and "or", the cryptic unpronounceable nature of "??" becomes much harder to ignore. "a and b" -> pronounced "a and b" "a or b" -> pronounced "a or b" "a ?? b" -> pronounced "a b" The only potentially pronounceable versions I've been able to come up with are a fair bit longer: "a if def else b" -> pronounced "a if defined, else b" "a if ?? is not None else b" -> pronounced "a if the leftmost operand is not None, else b" "a if ?? is None else ??.b" -> pronounced "a if the leftmost operand is None, else the leftmost operand dot b" (The last two examples there are a version where "??" appearing in either the condition expression or the RHS of a conditional expression would cause the leftmost operand to be eagerly evaluated, placed in a hidden temporary variable and then referenced multiple times as a subexpression. A similar construct could then also be used in filter expressions in comprehensions to refer back to the loop's result clause: "[f(x) for x in iterable if ?? is not None]". It's still magical and hard to look up syntax, but "??" as a magic placeholder to say "Reference the leftmost operand in the current expression here, but still only evaluate it once" seems nicer to me than using it as a cryptic binary operator) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

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" wrote: On 29 November 2017 at 16:13, David Mertz 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). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 29.11.2017 9:08, Steven D'Aprano wrote:
> On Tue, Nov 28, 2017 at 12:31:06PM -0800, Raymond Hettinger wrote:
>>> I also cc python-dev to see if anybody here is strongly in favor or against this inclusion.
>> Put me down for a strong -1.  The proposal would occasionally save a
>> few keystokes but comes at the expense of giving Python a more Perlish
>> look and a more arcane feel.
> I think that's an unfair characterisation of the benefits of the PEP.
> It's not just "a few keystrokes".
>
> Ironically, the equivalent in Perl is // which Python has used for
> truncating division since version 2.4 or so. So if we're in danger of
> looking "Perlish", that ship has sailed a long time ago.
>
> Perl is hardly the only language with null-coalescing operators -- we
> might better describe ?? as being familiar to C#, PHP, Swift and Dart.
> That's two mature, well-known languages and two up-and-coming languages.
My experience with these operators in C# says:
* They do save "more than a few keystrokes". Even more importantly, they 
allow to avoid double evaluation or the need for a temporary variable 
workaround that are inherent in " if  else "
     * (An alternative solution for the latter problem would be an 
assignment expression, another regularly rejected proposal.)
* They make it temptingly easy and implicit to ignore errors.
* They are alien to Python's standard semantics on search failure which 
is to raise an exception rather than return None
>
> [...]
>>      timeout ?? local_timeout ?? global_timeout
> As opposed to the status quo:
>
>      timeout if timeout is not None else (local_timeout if local_timeout is not None else global_timeout)
>
> Or shorter, but even harder to understand:
>
>      (global_timeout if local_timeout is None else local_timeout) if timeout is None else timeout
>
> I'd much prefer to teach the version with ?? -- it has a simple
> explanation: "the first of the three given values which isn't None". The
> ?? itself needs to be memorized, but that's no different from any other
> operator. The first time I saw ** I was perplexed and couldn't imagine
> what it meaned.
>
> Here ?? doesn't merely save a few keystrokes, it significantly reduces
> the length and complexity of the expression and entirely cuts out the
> duplication of names.
>
> If you can teach
>
>      timeout or local_timeout or global_timeout
>
> then you ought to be able to teach ??, as it is simpler: it only
> compares to None, and avoids needing to explain or justify Python's
> truthiness model.
>
>
>>      'foo' in (None ?? ['foo', 'bar'])
> If you can understand
>
>      'foo' in (False or ['foo', 'bar'])
>
> then surely you can understand the version with ??.
>
>
>>      requested_quantity ?? default_quantity * price
> Again:
>
>      (default_quantity if requested_quantity is None else requested_quantity) * price
>
>
> I'd much prefer to read, write and teach the version with ?? over the
> status quo.
>
>

-- 
Regards,
Ivan

On Thu, Nov 30, 2017 at 08:02:08PM +0300, Ivan Pozdeev via Python-ideas wrote:

My experience with these operators in C# says: * They do save "more than a few keystrokes". Even more importantly, they allow to avoid double evaluation or the need for a temporary variable workaround that are inherent in "<expr> if <expr> else <alternative>"     * (An alternative solution for the latter problem would be an assignment expression, another regularly rejected proposal.) * They make it temptingly easy and implicit to ignore errors.

How?

* They are alien to Python's standard semantics on search failure which is to raise an exception rather than return None

Alien, like this? py> mo = re.match(r'\d:', 'abc') py> mo is None True Besides, who said this is limited to searching? I don't remember even a single example in the PEP being about searching. -- Steve

On 1 December 2017 at 13:40, Nick Coghlan wrote:

I genuinely don't think these kinds of operators are all that useful outside the specific domain of working with semi-structured hierarchical data stored in graph databases and document stores like MongoDB, ElasticSearch, and PostgreSQL JSONB columns, or else piping data between such stores and JSON consuming clients.

In that case, surely there are 3rd party libraries that help with extracting such data from raw objects? Or if not, how seriously has anyone looked at developing one? With the ability to create specialised getattr and getitem behaviour, is it really so difficult to produce a class that allows users to extract hierarchical data? I know it probably couldn't do as good a job as if there were dedicated syntax, but as a basis for a proposal that said "current best practice (using module XXX) looks like this, but would be improved with the following language support" it would help to ground the discussion in real use cases. In the context of comparisons with matrix multiplication, PEP 465 put a lot of time into explaining how all the ways of approaching the problem short of a language change had been tried and found wanting. Maybe PEP 505 should be held to a similar standard? At the moment, 99% of the discussion seems rooted in generalised "it would help a lot of code" with readability arguments based on artificial examples, and that's not really helping move the discussion forward. To be clear, I understand the problem of reading semi-structured data. I've hit it myself and been frustrated by it. But my reaction was "why am I not able to find a library that does this?", and when I couldn't find such a library, my assumption was that people in general don't find the current behaviour sufficiently frustrating to do anything about it. And I was in the same situation - it annoys me, but not enough to write a helper module (and certainly not enough that I'm crying out for a language change). So I do appreciate the need, I just don't think "language change" should be the first thing that's suggested. Paul PS Some of the above may have been covered in the PEPs and previous discussions. I haven't reread them - but any serious reboot of the discussion should probably start with a summary of where we're up to.

On 2 December 2017 at 00:16, Paul Moore wrote:

At the moment, 99% of the discussion seems rooted in generalised "it would help a lot of code" with readability arguments based on artificial examples, and that's not really helping move the discussion forward.

PEP 505 covers this in https://www.python.org/dev/peps/pep-0505/#motivating-examples (with an actual survey of standard library code, as well as some specific motivating examples from real world open source projects).

To be clear, I understand the problem of reading semi-structured data. I've hit it myself and been frustrated by it. But my reaction was "why am I not able to find a library that does this?", and when I couldn't find such a library, my assumption was that people in general don't find the current behaviour sufficiently frustrating to do anything about it. And I was in the same situation - it annoys me, but not enough to write a helper module (and certainly not enough that I'm crying out for a language change). So I do appreciate the need, I just don't think "language change" should be the first thing that's suggested.

The problem is that libraries don't have any way to manipulate attribute access chains in a usefully relevant way - you either have to put the control flow logic in line, or start writing helper functions like: def maybe_traverse_particular_subtree(obj): if obj is None: return None return obj.particular.subtree.of.interest And there are lots of other tricks used to make such code reasonably readable, with one of the most common being "Use a short placeholder variable name", so you get code like: fs = site.first_seen first_seen = fs if fs is None else fs.isodate() (from one of the proposed refactorings of the SiteView example in the PEP) Another variant on the "?? as pronoun" idea would be to use it as a new syntax for defining single argument lambda expressions: def call_if_not_none(lhs, deferred_rhs): return lhs if lhs is not None else deferred_rhs(lhs) first_seen = call_if_not_none(site.first_seen, (??.isodate()) However, I think that would actually be less clear and more confusing than the inline implicit pronoun idea. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia