[Python-ideas] Modern language design survey for "assign and compare" statements
Carl Smith
carl.input at gmail.com
Sat May 19 15:57:08 EDT 2018
> 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 at gmail.com
On 19 May 2018 at 19:07, Kirill Balunov <kirillbalunov at gmail.com> wrote:
>
>
> 2018-05-19 3:54 GMT+03:00 Mike Miller <python-ideas at mgmiller.net>:
>
>> 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 at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180519/7617dfb6/attachment-0001.html>
More information about the Python-ideas
mailing list