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? 2017-11-29 9:08 GMT+03:00 Steven D'Aprano : I'd much prefer to read, write and teach the version with ?? over the

status quo.

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. With kind regards, -gdg 2017-11-29 11:14 GMT+03:00 Nick Coghlan :

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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

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? ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. lele@metapensiero.it | -- Fortunato Depero, 1929.

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 Wed, 29 Nov 2017 18:14:36 +1000 Nick Coghlan wrote:

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

As someone who appreciates both the matrix multiplication operator and "async/await", I really don't think PEP 505-style operators (regardless of their spellings) fall into the same conceptual bucket. There's no risk of matrix multiplication operators bleeding into non-domain specific code, and the readers of domain specific code already know about the matrix multiplication operator and what it does (or they should anyway, since it's so damn useful). It's like "async/await": you won't find them in regular non-async code, so the mental burden only falls on specialists who write and read event-driven networking code (mostly, even though Guido would like to see parsers based on the idiom too :-)). Conversely, PEP 505-style operators may appear in everyday code regardless of their application domain or target. This in turn increases the mental burden for *everyone*. Regards Antoine.

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

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

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

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.

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.

29.11.17 14:39, Nick Coghlan пише:

"a if def else b" -> pronounced "a if defined, else b"

I understand "a if defined, else b" as try: result = a except (NameError, AttributeError, LookupError): result = b The problem is that None is not undefined. This is a regular value. Seems it is not so special in Python as NULL or undef in other languages. Python even don't have a special purposed NullPointerException (or NoneError).

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