What about a more general: A if B else C which would allow A if is not None else C but also e.g. A if >= 1 else 0 Stephan Op 29 nov. 2017 13:41 schreef "Nick Coghlan" :

On 29 November 2017 at 22:38, Stephan Houben wrote:

...

What about more English-like syntax:

X or else Y

The problem with constructs like this is that they look like they should mean the same thing as "X or Y".

Cheers, Nick.

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

On Wed, Nov 29, 2017 at 3:12 PM Serhiy Storchaka wrote:

29.11.17 15:01, Stephan Houben пише:

...

What about a more general:

A if B else C

which would allow

A if is not None else C

but also e.g.

A if >= 1 else 0

This look the most "natural" to me. I.e. the least "unnatural". If we even will introduce a new special syntax I will prefer this syntax.

The only disadvantage is that this will prevent introducing "angular parenthesis" in future: A if == B else C.

Also, how do you treat more complex conditions? do you prohibit them? A if >= 0 and < 2 else 0 B if >= 0 or < -1 else -1 C if and B else A # i.e. C if C and B else E D if -y else E # is this an unary minus or a binary operation? If any of these is allowed, it might confuse people. It also break the ability to extract subexpression to variables. (I kinda like this idea, but it doesn't look like a small, simple change to the language, whereas ?? does). Elazar

Op 29 nov. 2017 22:35 schreef "Greg Ewing" : It would read better with some kind of pronoun in there: A if it is not None else C Hypercard's Hypertalk had a special variable "it" that worked sort of like that. I considered that, but there are two issues. 1. Backward-incompatible change 2. The semantics of A if B else C now depends on if B contains 'it', in which case A gets evaluated unconditionally and prior to B. What if evaluation of 'it' is itself conditional, e.g. print("hello") if a or it else print("goodbye") Note that in the A if B else C proposal the evaluation of the implicit 'it' is never conditional in that way. Stephan -- Greg _______________________________________________ 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 12:41, Nick Coghlan wrote:

On 29 November 2017 at 22:38, Stephan Houben wrote:

...

What about more English-like syntax:

X or else Y

The problem with constructs like this is that they look like they should mean the same thing as "X or Y".

Keyword based and multi-word approaches also break down much faster when you get more terms. X or else Y looks OK (ignoring Nick's comment - I could pick another keyword-based proposal, but I'm too lazy to look for one I like), but when you have 4 options, X or else Y or else Z or else W the benefit isn't as obvious. Use lower-case and longer names item_one or else item_two or else list_one[the_index] or dict_one['key_one'] and it becomes just a muddle of words. Conversely, punctuation-based examples look worse with shorter variables and with expressions rather than identifiers: item_one ?? item_two ?? another_item ?? one_more_possibility vs x ?? y[2] ?? kw['id'] ?? 3 + 7 IMO, this is a case where artificial examples are unusually bad at conveying the actual feel of a proposal. It's pretty easy to turn someone's acceptable-looking example into an incomprehensible mess, just by changing variable names and example terms. So I think it's critically important for any proposal along these lines (even just posts to the mailing list, and definitely for a PEP), that it's argued in terms of actual code examples in current projects that would reasonably be modified to use the proposed syntax. And people wanting to be particularly honest in their proposals should probably include both best-case and worst-case examples of readability. Paul PS Also, I want a pony. (I really do understand that the above is not realistic, but maybe I can hope that at least anyone writing a PEP take it into consideration :-))

On 2017-11-29 21:27, Greg Ewing wrote:

Nick Coghlan wrote:

...

...

What about more English-like syntax:

X or else Y

The problem with constructs like this is that they look like they should mean the same thing as "X or Y".

How about:

x otherwise y

It looks different enough from "or" that you're not going to accidentally read it that way when skimming.

The meaning is something you'll have to learn if you don't know, but at least it's a word that can be googled for.

It has the disadvantage that it's quite long. How about "alt" (abbreviation for "alternatively"): x alt y

On Wed, 29 Nov 2017 at 13:28 Greg Ewing wrote:

Nick Coghlan wrote:

...

...

What about more English-like syntax:

X or else Y

The problem with constructs like this is that they look like they should mean the same thing as "X or Y".

How about:

x otherwise y

It looks different enough from "or" that you're not going to accidentally read it that way when skimming.

The meaning is something you'll have to learn if you don't know, but at least it's a word that can be googled for.

In terms of syntax, this is my favourite one so far.