Conclusions

------------

It appears assignment expressions are no longer the favored solution for the "assign and compare" use case. Not one of these five newer languages supports them fully, as the language generations from C to C# did.

Of those that have recognized the use case to be large enough—the solution has been rather more limited to the "if" and "while" statements only. Several folks here have expressed the same desire to confine AE there. Since Python's design goals are similar—to be safe and maintainable I'd recommend a similar strategy, with the addition of the list comprehension case. Going back to the C-style solution seems like the wrong direction.

Since that would mean this special assignment functionality is not allowed to be used everywhere, it alleviates the pressure to make it fit into with/import/except statements. Furthermore, that frees up the keyword "as" again, which is Pythonic, short, memorable and has a history of being used for various assignment purposes, not to mention a prominent feature of SQL.

In short, extend the "if/elif", "while", and comprehension to:

if pattern.search(data) as match: …

while read_next_item() as value: …

May be best to disallow multiple assignment/conditions for now, but up for discussion. That leaves comprehensions, which could support a EXPR as NAME target also:

filtered_data = [f(x) as y, x/y for x in data]

or perhaps reuse of the if…as statement to keep it simpler:

filtered_data = [y, x/y for x in data if f(x) as y]

That variant might need an extra test if f(x) returns a falsey value, perhaps "is not None" on the end.

Thoughts? -Mike

Thanks for the research! Which is the niche, and how influential can it be, to have Python divert from the well learned "assignments must be statements". Cheers! -- Juancarlo *Añez*

On Sat, May 19, 2018 at 12:11 PM, Greg Ewing wrote:

Chris Angelico wrote:

...

The 'as' syntax has been hammered out in great detail and is no longer recommended due to its negative interactions with existing constructs.

Allowing it in arbitrary expressions has been ruled out on the grounds that the difference between "with x as y:" and "with (x as y):" would be too subtle.

But that argument doesn't apply if "as" becomes part of the syntax of "if" and "while". Do we think that's a bad idea as well?

Yes, largely because it's insufficient for all but a small handful of situations. I mentioned that in the previous email. ChrisA

On 19 May 2018 at 10:54, Mike Miller wrote:

Background:

While the previous discussions about assignment-expressions (PEP 572) (abbreviated AE below) have been raging one thing that was noticeable is that folks have been looking back to C for a solution.

But how are newer languages solving the problem today? Believe Ryan brought this up first on the list, but it had been in the back of my mind as well. Finally have compiled my research, corrections welcome.

Thank you for compiling this! It's a very useful point of reference :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Paul Svensson wrote:

I don't quite get what's so subtle about it, am I missing something?

The "with" keyword calls "__enter__", and "as" gives it a name.

Just like "-x + y" is different from "-(x + y)",

I think the difference is that mentally one already tends to think of "with x as y" being grouped "with (x as y)" rather than "(with x) as y". So, if "x as y" becomes a legal expression all by itself, it will *seem* as though the meaning of "as" is changed simply by adding explicit parentheses around an expression that was already implicitly parenthesised. Whether this is too subtle or not is a matter of opinion, but it was raised as one of the objections to using "as", so some people obviously thought so. -- Greg

On Sat, May 19, 2018 at 02:11:38PM +1200, Greg Ewing wrote:

Chris Angelico wrote:

...

The 'as' syntax has been hammered out in great detail and is no longer recommended due to its negative interactions with existing constructs.

Allowing it in arbitrary expressions has been ruled out on the grounds that the difference between "with x as y:" and "with (x as y):" would be too subtle.

But that argument doesn't apply if "as" becomes part of the syntax of "if" and "while". Do we think that's a bad idea as well?

Yes. What is so special about "if" and "while" that they and they alone can make use of assignment expressions? The `and` and `or` short-cut operators are only useful in `if` and `while` statements, so we ought to prohibit them outside of `if` and `while` statements. Do you agree? Either assignment expressions are useful, and they should be allowed anywhere an expression is allowed, or they aren't, and they shouldn't be allowed at all. Breaking the rules for a special case is rarely the right decision.

From the survey of other modern languages that was just posted, it seems we'd be in good company if adopted something like that.

/s/good/bad/ Compared to the Zen of Python, Go seems to break all the rules. Or at least most of them -- the beauty of the Zen is that it is open to interpetation :-) Go doesn't have exceptions. It requires the use of the tedious old anti-pattern of flag, result = function() if flag: do what you want else: # Now how the hell do I handle this? as a fundamental design principle, apparently because ugly and tedious boilerplate is a good thing, giving us all the verbosity of EAFP at its worst without any of the benefits. Similarly, its 2018 and the designers of Go turned their back on about 4/5th of the world, insisting that strings are ASCII and Unicode is an afterthought. I'm sure Rob Pike has his reasons for prohibiting exceptions, and network engineers probably think text is just another data format. Go might be an awesome language for what it is designed to do, but Forth is an awesome language for what it does best too, and we don't copy Forth's way of doing things. Before we copy Go, whether we copy a feature or a lack of feature, we ought to carefully consider how well that fits Python. (Sorry to just pick on Go, but it is the one I'm most familiar with.) -- Steve

On 2018-05-19 06:41, Steven D'Aprano wrote:

Thanks for writing up the summary, but you have picked a very narrow subset of new languages. One might even say a biased subset. How about these new languages?

Certainly. I chose basically on whether it was well used (popular), I'd heard about it, and it was easy to find documentation/discussion on. Then I ran out of energy around number six, haha. But I think this is representative of industry trends. -Mike

2018-05-19 3:54 GMT+03:00 Mike Miller :

Background:

While the previous discussions about assignment-expressions (PEP 572) (abbreviated AE below) have been raging one thing that was noticeable is that folks have been looking back to C for a solution.

But how are newer languages solving the problem today? Believe Ryan brought this up first on the list, but it had been in the back of my mind as well. Finally have compiled my research, corrections welcome. In alphabetical order:

Thank you Mike this is a very useful analysis. It would be also great to know when they introduced this feature - from the beginning or after a while. Your results are completely consistent with all the examples from the numerous threads - that this feature should be added only in `while` and `if` statements. [Chris] The bit that you tag on as an afterthought is actually critically

important here. You have two options: 1) The 'as' is part of the syntax of the 'if' and 'while' statements; or 2) The 'as' is part of the definition of an expression. The first case would be grammar like this: if_stmt: 'if' test ['as' NAME] ':' suite ('elif' test ':' suite)* ['else' ':' suite] The second is permitting 'as' name-bindings in arbitrary expressions, but then saying "except that they're only allowed in 'if' statements". As you've noted, the first one isn't sufficient. You can't use the restricted syntax for more than a small handful of conditions (including re.match(), but not including anything that might return None and might return other falsey values). So if this is valid: if (f(x) as y) is not None: then why isn't this valid: print(f(x) as y) or this: f(x) as y # identical to "y = f(x)" or even this: with (f(x) as y):

I think I have a very strong argument "why are not others valid" - Because already three months have passed and among 1300+ messages there was not a single real example where assignment expression would be convenient or useful outside `while` and `if` statements. If you have a counterargument (with an example), I would be glad to see. This thread is about the design choices which were made in other modern languages. And from Mike's analysis it is evident that other languages have chosen to allow the assignment as an expression only where it is practical - in `while` and `if` statements, or not to allow it at all. I find this at least absolutely not constructive to push `print(f(x) as y)` or `print(y:=f(x))` in every thread. Is this really the only compelling example outside `while` and `if`? Also if we consider only the usage in `while` and `if` statements, what is the point of discussing differences between `with (f(x) as y)` and `with f(x) as y`? The first one will be a ` SyntaxError`, period. Can you also explain why the assignment expression should be valid outside `while` and `if` statements? - for dummy consistency? The `as` variant was _hammered_ only in the general case, which in itself does not make sense (which is confirmed by 1300+ messages without examples). Some time ago Guido said that he is not _impressed_ with `as` variant. But I think he does not like this form because it does not play well in general case. There are several reasons why. The main one is if `as` will be accepted it will prevent the use of this form in theoretically future statements (for example match statement). Another point that it looks ugly for general case. As it seems to me, the intersection with `with`, `except` is also important but can be overcomed. The use of any system requires some study and understanding. BUT I also think that Guido will not so strongly object if only `while` and `if` statements were under consideration, because there is no other choice. Examples from other languages are very important and their choice should be taken into account. Those languages are also designed by smart guys and I'm sure that they were thinking about where the assignement expression should be allowed and 1300+ messages only confirm their choice. Therefore, it may be worthwhile to focus only on actual use cases - in `while` and `if` statements??? and stop to flood every thread with dummy examples. p.s.: I deliberately did not mention the pseudo _usefulness_ of assignment expression in generators/comprehensions because the benefits are very questionable. Therefore, to begin with, we should start with `while` and `if` statements, and possibly in the future add it to comprehensions/generators. With kind regards, -gdg

JavaScript and PHP are abysmally designed languages, so we should put little weight on any precedent they set.

JavaScript has issues, due to its unique history, but to dismiss the entire language as too poorly designed to take seriously... Many clever people prefer JS to Python. -- Carl Smith carl.input@gmail.com On 19 May 2018 at 19:07, Kirill Balunov wrote:

2018-05-19 3:54 GMT+03:00 Mike Miller :

...

Background:

While the previous discussions about assignment-expressions (PEP 572) (abbreviated AE below) have been raging one thing that was noticeable is that folks have been looking back to C for a solution.

But how are newer languages solving the problem today? Believe Ryan brought this up first on the list, but it had been in the back of my mind as well. Finally have compiled my research, corrections welcome. In alphabetical order:

Thank you Mike this is a very useful analysis. It would be also great to know when they introduced this feature - from the beginning or after a while. Your results are completely consistent with all the examples from the numerous threads - that this feature should be added only in `while` and `if` statements.

[Chris]

The bit that you tag on as an afterthought is actually critically

...

important here. You have two options: 1) The 'as' is part of the syntax of the 'if' and 'while' statements; or 2) The 'as' is part of the definition of an expression. The first case would be grammar like this: if_stmt: 'if' test ['as' NAME] ':' suite ('elif' test ':' suite)* ['else' ':' suite] The second is permitting 'as' name-bindings in arbitrary expressions, but then saying "except that they're only allowed in 'if' statements". As you've noted, the first one isn't sufficient. You can't use the restricted syntax for more than a small handful of conditions (including re.match(), but not including anything that might return None and might return other falsey values). So if this is valid: if (f(x) as y) is not None: then why isn't this valid: print(f(x) as y) or this: f(x) as y # identical to "y = f(x)" or even this: with (f(x) as y):

I think I have a very strong argument "why are not others valid" - Because already three months have passed and among 1300+ messages there was not a single real example where assignment expression would be convenient or useful outside `while` and `if` statements. If you have a counterargument (with an example), I would be glad to see.

This thread is about the design choices which were made in other modern languages. And from Mike's analysis it is evident that other languages have chosen to allow the assignment as an expression only where it is practical - in `while` and `if` statements, or not to allow it at all.

I find this at least absolutely not constructive to push `print(f(x) as y)` or `print(y:=f(x))` in every thread. Is this really the only compelling example outside `while` and `if`? Also if we consider only the usage in `while` and `if` statements, what is the point of discussing differences between `with (f(x) as y)` and `with f(x) as y`? The first one will be a `SyntaxError`, period. Can you also explain why the assignment expression should be valid outside `while` and `if` statements? - for dummy consistency? The `as` variant was _hammered_ only in the general case, which in itself does not make sense (which is confirmed by 1300+ messages without examples).

Some time ago Guido said that he is not _impressed_ with `as` variant. But I think he does not like this form because it does not play well in general case. There are several reasons why. The main one is if `as` will be accepted it will prevent the use of this form in theoretically future statements (for example match statement). Another point that it looks ugly for general case. As it seems to me, the intersection with `with`, `except` is also important but can be overcomed. The use of any system requires some study and understanding. BUT I also think that Guido will not so strongly object if only `while` and `if` statements were under consideration, because there is no other choice.

Examples from other languages are very important and their choice should be taken into account. Those languages are also designed by smart guys and I'm sure that they were thinking about where the assignement expression should be allowed and 1300+ messages only confirm their choice. Therefore, it may be worthwhile to focus only on actual use cases - in `while` and `if` statements??? and stop to flood every thread with dummy examples.

p.s.: I deliberately did not mention the pseudo _usefulness_ of assignment expression in generators/comprehensions because the benefits are very questionable. Therefore, to begin with, we should start with `while` and `if` statements, and possibly in the future add it to comprehensions/generators.

With kind regards, -gdg

_______________________________________________ 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 2018-05-18 18:10, Chris Angelico wrote:

The bit that you tag on as an afterthought is actually critically important here. You have two options:

1) The 'as' is part of the syntax of the 'if' and 'while' statements; or

This first choice appears the more conservative compromise that several have chosen (substituting "as" with "let"), only as part of the these two statements. -Mike

On 2018-05-18 19:14, Chris Angelico wrote:

Yes, largely because it's insufficient for all but a small handful of situations. I mentioned that in the previous email.

I'd argue that they are the bulk of occurrences, that's why they've been chosen as the compromise in those languages. Once there is an assignment and two compares, the time to break up the statement is approaching quickly, no? -Mike

On 2018-05-19 06:41, Steven D'Aprano wrote:

Details follow below.

Thanks for this, had some more time to read it more closely. Correct me if I'm probably wrong, but most of these are not used by many. Except perhaps: - Typescript, which is constrained by a compatibility goal with JavaScript. - Julia, - Possibly Elixir, have heard good things about it. My focus was on "industry standard" languages however, not pushing the envelope too far but rather on humdrum bug reduction and maintainability, an area Python aspires to, I believe. There was a stack overflow survey recently, should probably dig that up. -Mike

On Sat, May 19, 2018 at 04:28:10PM -0700, Mike Miller wrote:

On 2018-05-19 06:41, Steven D'Aprano wrote:

...

Details follow below.

Thanks for this, had some more time to read it more closely. Correct me if I'm probably wrong, but most of these are not used by many. Except perhaps:

According to the latest survey on TIOBE (May 2018), *none* of the languages either of us surveyed are used by more than a small niche. I realise that the TIOBE ranking is not the only available ranking, nor is their methodology necessarily the best, but if other people want to look at other language surveys they are free to do so. According to TIOBE, the rankings of your five languages are: Go #14 (up two places) 0.970% Swift #19 (down six places) 0.907% Dart #26 0.859% Kotlin #49 0.292% Rust #51-100 (percentages too small to differentiate) So even the most popular of your languages are still very niche. Go and Swift have a lot of industry "buzz" about them, but that's not translating to jobs or Google searches yet. The thirteen languages I surveyed are in a similar position: the highest ranked of them is Julia at #46. (I don't think TIOBE distinguishes between Perl at #18 and Perl 6.) Almost by definition, any new language is going to only be used by a small subset of programmers. [...]

My focus was on "industry standard" languages however,

I'm sorry, but no it wasn't. If we want *industry standard* languages, none of them are going to be *new*, and we need to look at those at the top of the TIOBE rankings: Java C C++ Python C# VB .Net PHP Javascript SQL Ruby R Delphi/Object Pascal Go and Swift are backed by large comporations and may some day be "industry standard", but they aren't yet. [Aside: it is sobering to realise that according to at least one objective ranking, "ancient and obsolete" Pascal is still more popular than "cool" new languages like Go and Swift.] I've somewhat arbitrarily cut the list off at "languages ranked above 1% on TIOBE", but we have to cut the list of somewhere. And of course in certain specific industries the standard languages may be very different, e.g. there are still tens of millions of lines of COBOL code being maintained in the banking industry. Out of those industry standard languages (as ranked by TIOBE, other methodology may result in other rankings) we find: 8/12 have some form of assignment expressions; (Java, C, C++, C#, PHP, Javascript, Ruby, R) 4/12 do not (Python, VB .Net, SQL, Delphi). -- Steve

On Sat, May 19, 2018, 11:07 Kirill Balunov wrote:

I think I have a very strong argument "why are not others valid" - Because already three months have passed and among 1300+ messages there was not a single real example where assignment expression would be convenient or useful outside `while` and `if` statements. If you have a counterargument (with an example), I would be glad to see.

comprehensions. I don't think you read any of the messages. about 1000 were solely about comprehensions. How about every example brought up in 1300+ messages that assignment expressions could handle that otherwise required far more code? Some including imports? Did you miss where _every_ counter example was either doing what assignment expressions do with more code, or where outright misunderstandings of how they will work? Did you read Chris' responses where he clearly refused each example? Really hard to see how you got that take away if you read those messages. Basically you are not backed up at all by citing that. assignment expressions handle many cases with ONE syntax. They are the "one way to do it" where "it" covers every example brought up so far.

On Sun, May 20, 2018 at 12:21:16AM -0500, Tim Peters wrote:

I was an early REBOL user, and my head still hurts ;-) It was ... different, for sure. [...]

Yeah, to me it looks more like a prefix version of Forth than Lisp. Complete with "anything can be a name":

Yup! "i1+2=3*88" is a variable name there :-)

but maybe when languages are weird enough they all look the same :-)

Short course: definitely "yes" on assignment expressions for Red. But I'm going to out on a limb and guess that the typical Python programmer wouldn't find "but Red does it!" persuasive ;-)

True :-) Thanks for doing the testing. -- Steve

On Sun, May 20, 2018 at 1:35 AM, Steven D'Aprano wrote:

but maybe when languages are weird enough they all look the same :-)

https://www.dreamsongs.com/WorseIsBetter.html Look at what happened with PERL... IMPORTANT NOTE: Enabling "as" in "if" and "while" doesn't have to be at the expense of some form of assignment expression. We've been having this discussion as if has to be either one or the other, and there's no reason we can't have both (as mentioned before, "reduce()" is live and well in the libraries, for people who need to use it). I in particular would not like it at all if something like ":=" was at the expense of "as", and I think that others on the side of expanding "if" and "while" may feel the same way. As a reminder, some of the arguments in favor of "as" are around the patterns exemplified by the "re" module; patterns which seem correct and useful, and that are used by other standard and 3rd-party modules. if os.fork() as child_pid: parent(child_pid) else: child() Cheers! -- Juancarlo *Añez*

You seem determined to throw out requirements when it suits. One of which was for newer languages. While this thread's original post was not so specific on that, in a previous post (I believe you read) defined that as created in the "last decade or so". The ones created to address shortcomings in the previous generation. The point being to find momentum in design of newer languages. Your list of older languages is therefore not pertinent. -Mike On 2018-05-19 18:43, Steven D'Aprano wrote:

Java C C++ Python C# VB .Net PHP Javascript SQL Ruby R Delphi/Object Pascal

What would be the benefit of adding the "as child_pid" syntax? The full assignment expression syntax completely covers all the jobs that you can do with a capturing if statement.

The "as" syntax over "if" and "while" may go in with all the restrictions and caveats already discussed. The discussion about the semantics of how ":=" should affect the enclosing context when used in generators, etc. may continue for as long as it must. And there are some of us who like the consistency of "us", and would shy away from ":=". For example, Should this be valid? if child_pid := os.fork(): parent(child_pid) else: child() print(child_pid) This shouldn't be: if os.fork() as child_pid: parent(child_pid) else: child() print(child_pid) # child_pid is undefined -- Juancarlo *Añez*

[Tim]

...

I was an early REBOL user, and my head still hurts ;-) It was ... different, for sure.

[Steven D'Aprano ]

Yeah, to me it looks more like a prefix version of Forth than Lisp. Complete with "anything can be a name":

The example I gave just strung "words" together, but just as fundamental is the notion of "block": a series of words and/or blocks enclosed in square brackets. That's akin to Lisp's "S expressions", but Rebol/Red _don't_ "evaluate" blocks by default. Blocks can hold data or code, or a mix of both, and the syntax doesn't care. That's the real reason "(almost) anything can be a name (word)". Here I'll build to a simple example where _some_ Pythoneers will experience envy rather than revulsion ;-)

...

[x y] == [x y]

The block isn't evaluated. Depending on how it's _used_, it may be treated as data (perhaps you want to think of it as being a sequence of two symbols, or strings). If you evaluate it, it blows up (because I don't happen to have any variables with those names defined):

...

do [x y] *** Script Error: x has no value

Give the names some values, and _then_ it can be evaluated; and evaluating a block returns the value of the last expression in the block:

...

x: 12 y: 13 == 13 [x y] == [x y] do [x y] == 13

If you want a block with all the expressions' values, use `reduce` instead:

...

reduce [x y] == [12 13]

Code? Data? No difference. Here's the part where some Pythoneers will get jealous:

...

sum: func [x y] [x + y] == func [x y][x + y] sum 8 2 == 10

`func` is just another function that happens to build an anonymous function. It takes two blocks as arguments: a block containing the formal argument names, and a block with the code to execute. Both blocks are essentially "data" to `func`. It doesn't look much like Forth anymore ;-) Note that the following does exactly the same:

...

arglist: [x y] == [x y] body: [x + y] == [x + y] sum2: func arglist body == func [x y][x + y] sum2 8 2 == 10

In practice, slinging Rebol/Red most feels like working in a functional language. One of their real goals, though, is to enable writing functions that can be called like so: schedule "Change furnace filter" [ starting today then every 3 months ] There's an elaborate `parse` function built in that supports many ways of applying user-supplied rules to parse blocks like the one in that example. Of course you can emulate much the same in Python by, e.g., passing triple-quoted strings instead. In that specific example. Rebol/Red provide a minimum of syntax shared by all such applications, and when the sub-language gets elaborate enough that _nesting_ blocks makes good sense, nesting triple-quoted strings sucks ;-) All languages have some good things going for them. But I'm not sure I've ever seen Rebol/Red code that _used_ the value of an assignment expression; that it has them at all seems much more to follow from that everything is an expression. As in most functional languages, if you want initialized local variables, you're more likely to invoke an anonymous spelled-inline function instead. Which is what, e.g., Haskell's "let PILE_OF_BINDINGS in EXPRESSION" is syntactic sugar for doing.

On Sun, May 20, 2018 at 02:53:46PM -0400, Juancarlo Añez wrote:

This shouldn't be:

if os.fork() as child_pid: parent(child_pid) else: child()

print(child_pid) # child_pid is undefined

Why on earth would it be undefined? Anyway, if you want to propose an alternative to PEP 572, you ought to write your own competing PEP. -- Steve

[Tim, on Rebol/Red]

...

...

...

x: 12 y: 13 == 13 [x y] == [x y]

do [x y] == 13

[Greg Ewing ]

How does scoping work? If you pass a block to a function which evaluates it, how are names in the block resolved?

Too involved, but basically a form of lexical scoping. Rebol struggled with this, and details vary by version. Here are the last docs for version 2: http://www.rebol.com/r3/docs/concepts/funcs-scope.html Details changed again for version 3. Best I can tell, Red hasn't written up its own rules yet. The model did _not_ support closures naturally (in the sense of local bindings persisting beyond a function's return). Version 3 added an alternative to `func`, named `closure`, which could be used when you wanted a closure: http://www.rebol.com/r3/docs/datatypes/closure.html But I noticed just now that Red doesn't have `closure` built in, and its funcs don't support closures naturally either:

...

adder: func [x] [func [y] [x + y]] == func [x][func [y] [x + y]]

...

add3: adder 3 == func [y][x + y]

...

add3 12 *** Script Error: x is not in the specified context *** Where: add3 *** Stack: add3

That's not dynamic scoping, either - it's still unhappy if `x` is defined at top level:

...

x: 18 == 18 add3 12 *** Script Error: x is not in the specified context *** Where: add3 *** Stack: add3

On 20/05/18 06:19, Matt Arcidy wrote:

On Sat, May 19, 2018, 11:07 Kirill Balunov wrote:

...

I think I have a very strong argument "why are not others valid" - Because already three months have passed and among 1300+ messages there was not a single real example where assignment expression would be convenient or useful outside `while` and `if` statements. If you have a counterargument (with an example), I would be glad to see.

comprehensions. I don't think you read any of the messages. about 1000 were solely about comprehensions.

I'm afraid I haven't seen a convincing example of an useful assignment expression in a comprehension that wasn't also a convincing example of things that shouldn't have been comprehensions in the first place. -- Rhodri James *-* Kynesim Ltd

On 21 May 2018 at 12:05, Rhodri James wrote:

Thanks for the analysis, but I'm afraid I must disagree with your recommendation. It was the thought I first had when Chris came out with his first draft of the PEP several months ago, but it's not enough to cope with my usual use cases. What I normally want is the Python equivalent of:

while ((v = get_something()) != INCONVENIENT_SENTINEL) do_something(v);

The condition expression itself is not what I want to capture; I need a subexpression, which the "as" syntax won't give me.

That use case should be covered by for v in iter(get_something, INCOVENIENT_SENTINEL): do_something(v) -- https://www.machinalis.co.uk Daniel Moisset UK COUNTRY MANAGER A: 1 Fore Street, EC2Y 9DT London https://goo.gl/maps/pH9BBLgE8dG2 P: +44 7398 827139 <+44+7398+827139> M: dmoisset@machinalis.com | S: dmoisset http://www.linkedin.com/company/456525 http://www.twitter.com/machinalis http://www.facebook.com/machinalis https://www.instagram.com/machinalis.life/ Machinalis Limited is a company registered in England and Wales. Registered number: 10574987.

while ((v = get_something()) != INCONVENIENT_SENTINEL) do_something(v);

The current pattern in Python would be something like: v = get_something() while v != INCONVENIENT_SENTINEL: do_something(v) v = get_something() With "as" allowed in "while", they pattern might be: while get_something() as v: if v == INCONVENIENT_SENTINEL: break do_something(v) The discussion isn't over, so it could also be: while (get_something() as v) != INCONVENIENT_SENTINEL: do_something(v) Cheers, -- Juancarlo *Añez*

Sorry, hit send by accident. I meant to say: do_something(v) *if* v != INCONVENIENT_SENTINEL *else break* -- Carl Smith carl.input@gmail.com On 21 May 2018 at 13:37, Carl Smith wrote:

v = get_something()

while v != INCONVENIENT_SENTINEL:

do_something(v)

v = get_something()

I'd personally go with:

while True: v = get_something() if v != INCONVENIENT_SENTINEL: break do_something(v)

But it's not much different. I'd really like to be able to use jump statements in ternary expressions, like:

do_something(v)

But that's another story.

-- Carl Smith carl.input@gmail.com

On 21 May 2018 at 13:22, Juancarlo Añez wrote:

...

while ((v = get_something()) != INCONVENIENT_SENTINEL)

...

do_something(v);

The current pattern in Python would be something like:

v = get_something()

while v != INCONVENIENT_SENTINEL:

do_something(v)

v = get_something()

With "as" allowed in "while", they pattern might be:

while get_something() as v:

if v == INCONVENIENT_SENTINEL:

break

do_something(v)

The discussion isn't over, so it could also be:

while (get_something() as v) != INCONVENIENT_SENTINEL:

do_something(v)

Cheers,

-- Juancarlo *Añez*

_______________________________________________ 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 21/05/18 13:22, Juancarlo Añez wrote:

...

while ((v = get_something()) != INCONVENIENT_SENTINEL) do_something(v);

The current pattern in Python would be something like:

v = get_something()

while v != INCONVENIENT_SENTINEL:

do_something(v)

v = get_something()

Actually more usually while True: v = get_something() if v == INCONVENIENT_SENTINEL: break do_something(v) Inelegant and, as has been pointed out, frankly misleading about the nature of the loop, but at least you can tell what's going on fairly straightforwardly.

With "as" allowed in "while", they pattern might be:

while get_something() as v:

if v == INCONVENIENT_SENTINEL:

break

do_something(v)

The discussion isn't over, so it could also be:

while (get_something() as v) != INCONVENIENT_SENTINEL:

do_something(v)

These two are somewhat different things. -- Rhodri James *-* Kynesim Ltd

To clarify there were three main criteria, and one minor. Newer, popular/becoming industry standard, and designed to address shortcomings in previous generations. Finally, the limit of my energy when already working on a project. I also should have provided the link to the previous discussion. When writing the first message I indeed thought a wiki might be better, because I'd undoubtedly forget to mention, or inaccurately state something. Meta discussion: While I do prefer the "as" version of assignment, I didn't enter into the inquiry to prove it better, but rather to find industry momentum, and had only some minor exposure to go/kotlin via their tutorials beforehand. I did a similar thing when "f-string" design was debated. At first I wasn't in favor of them handling expressions, but after doing a survey of other modern/popular languages found it was working well elsewhere and changed my opinion. So it goes both ways, and I'm open to being convinced against my first preference and not heavily invested in it. -Mike

On 5/21/2018 9:14 AM, Rhodri James wrote:

On 21/05/18 12:29, Daniel Moisset wrote:

...

On 21 May 2018 at 12:05, Rhodri James wrote:

...

with my usual use cases.  What I normally want is the Python equivalent of:

   while ((v = get_something()) != INCONVENIENT_SENTINEL)      do_something(v);

...

That use case should be covered by

for v in iter(get_something, INCOVENIENT_SENTINEL):      do_something(v)

There are many ways round my use case, all of them inelegant.  That has to be one of the less comprehensible alternatives.

The following might be slightly clearer. item_iterator = iter(get_something, INCONVENIENT_SENTINEL) for item in item_iterator: do_something(item) I think iter is the right thing to use here. I think your contrary response is a least partly due to unfamiliarity with the two-argument form of iter and how it abbreviates and encapsulates the alternatives you already know. The essential idea of 'iter' is to produce iterators from Python objects. When the input is a function, sentinel pair, iter returns an instance of a internal callable_iterator class, equivalent to class callable_iterator def __init__(self, function, sentinel) self.function = function self.sentinel = sentinel def __iter__(self): return self def __next__(self): item = self.function() if item == self.sentinel: raise StopIteration return item If iter were actually written in Python, it might instead return the generator returned by a generator function encapsulating one of well-know while loop idioms. # Double call form. def function_sentinel(function, sentinel) item = function() while item != sentinel yield item item = function() # Loop and a half form; the loop body is essentially the same # as the body of callable_iterator.__next__, above def function_sentinel(function, sentinel): while True: item = function() # No 'self.' if item == sentinel: # No 'self.' break # Instead of 'raise StopIteration yield item # Instead of 'return item' The essential idea of for-loops is to cleanly separate sequential production of items to be processed, in the header, from processing of each item, in the body. It always calls iter(iterable) for you. If you need to pass two arguments to iter, you must do it explicitly. The while alternatives for this case intermix getting and processing items in the body. -- Terry Jan Reedy

Chris makes a lot of good points regarding *which* languages to look at, but it seems like that line of enquiry is unlikely to suggest anything more than it has so far, especially if we're limiting it to languages everyone has heard of. They either use a keyword, an operator, don't support the feature or they're wacky. If anything, the survey says we need to think outside the box. -- Carl Smith carl.input@gmail.com On 21 May 2018 at 20:11, Chris Angelico wrote:

On Tue, May 22, 2018 at 2:43 AM, Mike Miller wrote:

...

To clarify there were three main criteria, and one minor. Newer, popular/becoming industry standard, and designed to address shortcomings in previous generations. Finally, the limit of my energy when already working on a project.

Note how not one of your criteria says that the language has to have made the right choice - only that it's made a DIFFERENT choice to languages in a previous generation. So you're heavily selecting in favour of languages that say "hey look, we know better than everyone else does", without actually proving that it's better. There's no shortage of language designers who say "oh look how terrible C is", and when a language designer has a lot of clout behind him (like "apps for this new mobile phone should be written using this language"), it can get extremely popular among people who don't actually have much choice of language - and certainly don't have the option to use C.

Much more useful would be to look at languages that (a) work in a field where programmers have ample freedom to choose between languages, and (b) have been around long enough to actually demonstrate that people want to use them. Look through the Stack Overflow Developer Survey's report on languages:

https://insights.stackoverflow.com/survey/2018/ #most-loved-dreaded-and-wanted

A "Wanted" language is one that many developers say "I don't currently use, but I would like to". (It may also be a language that has murdered semicolons. I believe the bounty on JavaScript's head is quite high now.) Go through that list and you'll get an idea of what people wish they could use; then toss out anything that hasn't been around for at least 10 years, because there's a tendency for new technologies to be over-represented in a "Wanted" listing (partly because fewer programmers already know them, and partly because people want to try the latest toys). That may give you a better list of languages to compare against.

ChrisA _______________________________________________ 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 Mon, May 21, 2018 at 09:43:45AM -0700, Mike Miller wrote:

To clarify there were three main criteria, and one minor. Newer, popular/becoming industry standard, and designed to address shortcomings in previous generations. Finally, the limit of my energy when already working on a project.

To take your criteria in reverse order: 1. Why should the limit on *your* energy be a deciding factor? I was willing to spend a few hours doing a more complete sample of new languages. Should we ignore those because you ran out of energy? If anyone else wants to extend it even further, and survey more languages, we should welcome an even more extensive survey. 2. By definition, EVERY new language is designed to "address shortcomings in previous generations" of languages. If the designer thought previous languages were ideal, they wouldn't invent a new language. 3. None of the languages you surveyed are "popular/becoming industry standard" according to the closest thing we have to an objective measure of popularity: rankings like those provided by TIOBE. If you don't like TIOBE's methodology, feel free to propose a different, neutral, ranking. If you want a subjective opinion based on "industry buzz", then I would say that out of the five languages you listed, only two (Go and Swift) are anything close to "becoming industry standard", a tiny sample indeed, but nevertheless one where both languages have some form of assignment expressions (Go only in "if" statements, Swift everywhere). 4. What was your criteria for "newer"? I must admit I assumed it was languages invented since 2010, but I see Go was invented in 2009. If your cutoff is 2009, then we ought to include Coffeescript, which also has assignment expressions. -- Steve

On 2018-05-21 16:50, Steven D'Aprano wrote:

Your conclusion does not follow even from the limited sample of

They're not going in the direction of assignment-expressions everywhere, but rather one built in to the if/while statement. Coffeescript could certainly be a good candidate, though falling out of favor to typescript. Swift may allow them but are not useful when returning Void. -Mike

On Tue, May 22, 2018 at 10:45 AM, Mike Miller wrote:

On 2018-05-21 16:40, Steven D'Aprano wrote:

Consider the link Chris sent above:

https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wante...

The top six coincide with my list, plus TypeScript (superset of JS) and Python. I'm pretty happy with those chosen, considering.

But as I mentioned, the "wanted" list over-represents the new languages. For it to be useful to this discussion, you have to *reject* anything less than about ten years old. ChrisA

I don't know what to do with this thread. I enjoyed reading Mike's survey of what other languages do. I also enjoyed Chris's survey of what some other languages do. Then the thread veered off into several unproductive directions at once: a mini-tutorial for Rebol (or Red?), and endless bickering about which list of languages to allow in the survey. But that's not how this stuff gets decided. It's not the case that if we find that 90% of languages surveyed don't have inline assignment that means Python should not have it either. So changing the criteria for inclusion in the survey is entirely unproductive (except in that it may create a strong bonding experience between participants in the discussion -- though in this case perhaps the forces involved may be better described as repulsion than attraction :-). *Perhaps* it would help if we could ask those languages' designers for their rationale (most of them are still alive :-). But nobody proposed that. And it probably wouldn't help either, because the answers of actual language designers for such questions are typically a mixture of strongly held opinion on issues that aren't decidable based on hard facts alone, and hard but incredibly subtle facts related to the rest of the language's design and implementation (including the state of tooling and the structure of the compiler used as a reference implementation). So let's just end this thread. -- --Guido van Rossum (python.org/~guido)

On Tue, May 22, 2018 at 11:45 AM, Brendan Barnwell wrote:

On 2018-05-21 12:11, Chris Angelico wrote:

...

Much more useful would be to look at languages that (a) work in a field where programmers have ample freedom to choose between languages, and (b) have been around long enough to actually demonstrate that people want to use them. Look through the Stack Overflow Developer Survey's report on languages:

https://insights.stackoverflow.com/survey/2018/#most-loved-dreaded-and-wante...

A "Wanted" language is one that many developers say "I don't currently use, but I would like to". (It may also be a language that has murdered semicolons. I believe the bounty on JavaScript's head is quite high now.) Go through that list and you'll get an idea of what people wish they could use; then toss out anything that hasn't been around for at least 10 years, because there's a tendency for new technologies to be over-represented in a "Wanted" listing (partly because fewer programmers already know them, and partly because people want to try the latest toys). That may give you a better list of languages to compare against.

I'd say that also has limited usefulness. The problem is that people may "want" to learn a language for many reasons, and "the language made good design choices" is only one such reason. A lot of people may want to use JavaScript because it's hip or in demand or because they can (or think they can) make money with it. But I'm not so interested in that. What interests me is: what are the languages that people specifically believe are superior to other languages *in design*? (Even better would be what are the languages that actually ARE superior, in some reasonably nonsubjective, definable, way, but we have even less data on that.)

What you want is virtually impossible to obtain, so we go for whatever approximations we can actually get hold of. There are a few reasons someone might want to use a language. One is "I hate this language but it'll earn me money", yes, but the way the Stack Overflow survey is worded, those ones won't come up. IIRC the wording is "which languages do you desire to be using next year", after removing the ones for which you also said that you're using them now. So there are a good few reasons that you might wish you could be using a language: 1) You believe it's a good language, worth using, but just have never gotten around to starting with it 2) You think it's really fun and awesome, and wish your employer would let you use that instead of what you currently use 3) It represents a particular coding arena that you want to get into (eg you want to get into iOS development, so you pick "Swift") 4) It's an absolutely awesome language and you have plans to learn it, but haven't executed on them yet 5) It's a new language, and you want the shinies 6) Etc, etc, etc. Generally speaking, for a language to show up in the "Most Wanted", a lot of developers have to think it's something worth knowing. After cutting out the youngest languages (which I defined as "released within the last ten years") to remove their overrepresentation, you're left with languages that, in the opinions of people who don't yet program in them, are worth learning. That's far from an exact answer to the question we really want to ask, but it's reasonably concrete (to the extent that surveys ever are). But as Guido says, this is not a popular vote among languages. It's interesting to notice what other languages are doing, but harder to pin down what's good or bad about what they're doing. ChrisA

Le 20/05/2018 à 03:43, Steven D'Aprano a écrit :

I've somewhat arbitrarily cut the list off at "languages ranked above 1% on TIOBE", but we have to cut the list of somewhere. And of course in certain specific industries the standard languages may be very different, e.g. there are still tens of millions of lines of COBOL code being maintained in the banking industry. And also many lines of Matlab/Octave code in experimental science. Surprisingly enough, it seems that Matlab does not support AE, but GNU Octave does. I don't know if that was ever discussed when GNU Octave was designed.

octave:1> y=(x=2)+1 y =  3 octave:2> x x =  2 versus Matlab R2018b:

...

y=(x=2)+1  y=(x=2)+1      ↑ Error: Incorrect use of '=' operator. To assign a value to a variable, use '='. To compare values for equality, use '=='.

Julien