[Python-ideas] Re: `if-unless` expressions in Python
James Lu wrote: I think print("Remember to wear sunscreen!") if hot_outside unless Weather.is_raining() Is more readable than if hot_outside and not Weather.is_raining(): print("Remember to wear sunscreen!") That's very much a matter of opinion -- I find the second version considerably clearer. -- Greg ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XOOM2YNO2MEMJTFHGKRB3UOSPPJ5OVCG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
I'm concerned that in this thread, and elsewhere, we're not paying sufficient attention to https://en.wikipedia.org/wiki/Cognitive_load. Adding a feature to a system can increase the cognitive load in learning the system, and it can also reduce the cognitive load in using the system. Sometimes adding a feature can reduce cognitive load in both learning and using the system, but I suspect that is exceptional. I suggest that in this thread we have more discussion of the cognitive load adding this feature would add to those learning the system. I also suggest, as someone else has already done, that we focus more on the problem to be solved rather than a specific solution. -- Jonathan ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HJDDLK57OUMAOYTJKDV7IPAIEJGQ3MMC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On Jun 24, 2019, at 10:27, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 6/24/19 12:32 PM, James Lu wrote: > > > I think > > > > print("Remember to wear sunscreen!") if hot_outside unless > > Weather.is_raining() > > > > Is more readable than > > > > if hot_outside and not Weather.is_raining(): print("Remember to wear > > sunscreen!") > > I disagree, but that's bound to happen in a discussion like this. I also disagree. And I think there’s a principled reason for it. In a language like Perl, where there’s little consistency in syntax and flow control is scattered all over the place, this would be great. You can write the code in the same order as the sentence you’re thinking in your native language. In fact, Perl added postfix conditionals back in version 4 or so, and everyone loved it. But in Python, flow control is restricted to compound statements, which all have the same form: a colon and an indebted block. This makes Python a lot easier to read. While it’s _possible_ to escape from an expression by intentionally calling a function that raises, or to bury side-effect-only function calls deep in an expression, it’s considered bad style, and only done in rare, exceptional cases. What’s being proposed here is to add a new way to do that. So, either it’s deliberately encouraging bad style, or it’s something that would be so rarely used that it’s not worth it. What about comprehensions? They _do_ have flow control within an expression, and even spell it with a postfix condition. But comprehensions are a highly restricted mini-language, where the only flow control possible is skipping, and the syntax encourages you to keep them short and simple. So they turn out to be worth it. Which is exactly why the more restricted version of the proposal—only allowing “pass” (or however it’s spelled) inside displays (and “tuple displays”) and argument lists—might be worth it, even if the fully general one isn’t. That being said, I still haven’t seen an example of a function call or list display that actually looks compelling. I think if anyone wants to convince everyone that some form of this proposal is worthwhile, that’s the first thing they need to provide. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BGFUVTYMDHI27QAQ6XA6ZK677JOD44HV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On 6/24/19 12:32 PM, James Lu wrote: > I think > > print("Remember to wear sunscreen!") if hot_outside unless Weather.is_raining() > > Is more readable than > > if hot_outside and not Weather.is_raining(): print("Remember to wear sunscreen!") I disagree, but that's bound to happen in a discussion like this. > I think the unless syntax would be especially useful when there is a > series of functions like this. > > The general use case would be: > > side_effecting_expression if frequent_condition unless rare_condition Can you clarify "series of functions like this"? Are the functions the calls to print? Are the functions the calls to Weather.is_raining()? IMO, in a "series of logic like this," the fact that individual bits are the same should be blindingly obvious. With line after line of multiple bits (some side-effecting statement, two conditions, and some keywords), as opposed to a series of if statements with their associated inddented suites, I feel that the commonality will get lost. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JNZ3CGYGCNEHCVIKR7DHINSEJN4DEE5U/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On 2019-06-24 17:32, James Lu wrote: I think print("Remember to wear sunscreen!") if hot_outside unless Weather.is_raining() Is more readable than if hot_outside and not Weather.is_raining(): print("Remember to wear sunscreen!") I think the unless syntax would be especially useful when there is a series of functions like this. The general use case would be: side_effecting_expression if frequent_condition unless rare_condition Python isn't English, and I don't think we should be pushing it in that direction. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RWL3VFX6Q5PSWARHNLBPHNCB3XW2RGF3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On Tue, Jun 25, 2019 at 3:01 AM James Lu wrote: > > I think > > print("Remember to wear sunscreen!") if hot_outside unless > Weather.is_raining() > > Is more readable than > > if hot_outside and not Weather.is_raining(): print("Remember to wear > sunscreen!") > > I think the unless syntax would be especially useful when there is a series > of functions like this. > > The general use case would be: > > side_effecting_expression if frequent_condition unless rare_condition Can you find some non-toy examples where this forked condition is actually better than simply using a boolean operator? ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LCTBWDA4NFF4O66G2FY5EI5MJFVQBGDA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
Folks, Can I please remind people to trim their quoting? We readers shouldn't have to hit the Page Down key eight or nine times, or scroll down through five or six pages, to see the first new content. (I have a rule: if I haven't reached new content after nine screens of quoting, I give up and delete the email.) Quoting is supposed to show context, not to be a full record of the entire history of the thread. We have archives for that :) If you really can't trim the quoting (backspace key broken? feeble email client?) then speaking for myself, I'd rather you top-post so at least I can see your comments within a page or two of the start of the email. Thank you, Steven ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FXDQ4RMSQJLO2V7DFQJ4CYDAM4X5TLY3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On 2019-06-24 09:23, Chris Angelico wrote:> On Mon, Jun 24, 2019 at 6:03 PM Andrew Barnert wrote: >> >> On Sunday, June 23, 2019, 10:13:07 PM PDT, Chris Angelico wrote: >> >> > The biggest problem with this proposal is the way that, being a >> > syntactic construct, it's going to be non-composable. >> >> > # Oops, syntax error >> > with (some_expr as q, >> > some_other_expr as w): >> > pass >> >> I don't understand. Are you suggesting that some_expr could be something like "2 if cond else pass", so if not cond, this is supposed to be equivalent to "with ( as q, some_other_expr as w):", which is a SyntaxError (at runtime)? If so, that's the same problem as with most other syntactic locations where an expression can go, like the assignment example I gave earlier. >> > > Sorry, I kinda glossed over a lot of details there. > > The example that I gave is a SyntaxError, unrelated to the current > proposal. To make it work, you have to remove the parens, and use a > backslash to continue the line. And every now and then, someone > proposes to make the 'with' statement accept the form I gave, because > it would be cleaner. It isn't an easy change, because "with expr as > name" is a syntactic construct; the "expr as name" part cannot be > composed into a larger expression. > > The proposed syntax would have the exact same problem: > > stuff = [ > foo unless True, > bar unless False, > (quux("spam", "eggs", "sausage", "spam") > unless customer_wants("spam")) > ] > > This particular example would work if you just removed the parens (it > doesn't need a backslash to continue the line, since it's inside a > list display), but I can pretty much guarantee that people will put > parens around one of these sequences and then wonder why on earth it > doesn't work. > Well, I suppose it could work with parentheses, but not necessarily in the way you want/expect. If customer_wants("spam") returns False, then (quux("spam", "eggs", "sausage", "spam") unless customer_wants("spam")) could mean ()! (You could say that it doesn't, and if you want that behaviour then you should add a trailing comma.) ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3Q3GVWFCQXEBDGQ2QYWQEQBEESYE6WJK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Integer infinity and extended integers
Now that Python is beginning to embrace type annotations, is it worth revisiting the idea of having extended integers and an integer infinity? I found myself trying to annotate this line: events_to_do: Union[int, float] = math.inf where I am only including float in the union to accommodate math.inf. I'm interested in exploring this concrete proposal: Add a class to the numeric hierarchy (https://www.python.org/dev/peps/pep-3141/) ExtendedIntegral whereby Real :> ExtendedIntegral :> Integral. Add a sentinel math.int_inf that obeys all of the same kinds of rules as math.inf does. Then, I could annotate more simply: events_to_do: ExtendedIntegral = math.int_inf With respect to Python, this is discussed somewhat here https://stackoverflow.com/questions/24587994/infinite-integer-in-python/35725065#35725065. The name "extended integer" is discussed somewhat here https://math.stackexchange.com/questions/1442961/extended-integers. A quick search of papers shows that it is sometimes used in this sense: https://scholar.google.com/scholar?q=%22extended+integer Best, Neil ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QFLWTFJMU2RSGBMYP2XMSYA36VYFRDDQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On Mon, Jun 24, 2019 at 6:03 PM Andrew Barnert wrote: > > On Sunday, June 23, 2019, 10:13:07 PM PDT, Chris Angelico > wrote: > > > The biggest problem with this proposal is the way that, being a > > syntactic construct, it's going to be non-composable. > > > # Oops, syntax error > > with (some_expr as q, > > some_other_expr as w): > > pass > > I don't understand. Are you suggesting that some_expr could be something like > "2 if cond else pass", so if not cond, this is supposed to be equivalent to > "with ( as q, some_other_expr as w):", which is a SyntaxError (at runtime)? > If so, that's the same problem as with most other syntactic locations where > an expression can go, like the assignment example I gave earlier. > Sorry, I kinda glossed over a lot of details there. The example that I gave is a SyntaxError, unrelated to the current proposal. To make it work, you have to remove the parens, and use a backslash to continue the line. And every now and then, someone proposes to make the 'with' statement accept the form I gave, because it would be cleaner. It isn't an easy change, because "with expr as name" is a syntactic construct; the "expr as name" part cannot be composed into a larger expression. The proposed syntax would have the exact same problem: stuff = [ foo unless True, bar unless False, (quux("spam", "eggs", "sausage", "spam") unless customer_wants("spam")) ] This particular example would work if you just removed the parens (it doesn't need a backslash to continue the line, since it's inside a list display), but I can pretty much guarantee that people will put parens around one of these sequences and then wonder why on earth it doesn't work. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NGFOPEENZQMELX4SVVKU2NQNQXEBS3CU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: `if-unless` expressions in Python
On Sunday, June 23, 2019, 10:13:07 PM PDT, Chris Angelico wrote: > The biggest problem with this proposal is the way that, being a > syntactic construct, it's going to be non-composable. > # Oops, syntax error > with (some_expr as q, > some_other_expr as w):> pass I don't understand. Are you suggesting that some_expr could be something like "2 if cond else pass", so if not cond, this is supposed to be equivalent to "with ( as q, some_other_expr as w):", which is a SyntaxError (at runtime)? If so, that's the same problem as with most other syntactic locations where an expression can go, like the assignment example I gave earlier. Anyway, I think we need to make this more concrete. Python semantics aren't defined in terms of syntax rewriting rules, so trying to discuss this suggestion as if it were a syntax rewriting rule is only going to lead to confusion. If the restrictions on pass are to be syntactic, they're in the grammar, and "x = 2 if cond else pass" is a SyntaxError, at compile time, because it's not valid syntax for an assignment statement. If not, then they're defined in the semantics attached to the grammar; "x = 2 if cond else pass" is a valid assignment statement, whether cond is true or false, and some node in that statement's tree is going to tell us what it means—in this case, that it raises some error (let's all it NoValueError) at runtime if cond is false. Either way, I think you want to start with a restricted set of places pass can be used or propagated. If it's possible (and I'm pretty sure it is), it's much easier to just define the changed behavior of a handful of nodes we care about, than to grub through the entire language looking at how each construct would handle it. (Plus, you'd definitely want to be conservative here—adding pass-handling to return statement or or expressions in a later version breaks nothing, but removing it breaks working code.) So, pass has to change from a statement to an expression. And then you need to define the semantics of a few things: the new pass expression, the handful of places where you want pass is meaningful as a final value (I believe that's just 6.2.4 displays, 6.3.4 calls, 6.14 expression lists, and 7.1 expression statements), and the handful of places where pass can propagate up (that could be just 6,12 conditionals). For example, in 6.14, you change the first paragraph to say "… number of expressions in the list **that do not evaluate to pass**." In 6.12, you add "… y is evaluated and its value is returned. **In this case, if y evaluates to pass, the conditional evaluates to pass.**" If it's not syntactic, then you're almost done, you just need to add a new blanket rule that says that when an expression evaluates to pass in all cases except as specified otherwise, then a NoValueError is raised. So, "x = 1, 2 if spam else pass, 3" evaluates to (1, 3) when not spam because the semantics for expression list (and conditional expression) tell us what happen; "x = 2 if spam else pass" raises a NoValueError because assignment and expression don't specify otherwise. If it is syntactic, then you don't need that all-other-cases bit, and don't need the exception at all. Instead, you need to change the grammar in 6.12 and friends to use a new node called pass_expression instead of expression, and that node can include pass_conditional_expression instead of conditional_expression, and… propagate that forking as far into the grammar as you have to. Nw, "x = 2 if spam else pass" is a SyntaxError because "2 if spam else pass" is not an expression, but "x = 1, 2 if spam else pass, 3" is valid syntax because "2 if spam else pass" is a valid pass_expression, and therefore a valid starred_item, and therefore the whole list is a valid starred_list (which, at runtime, will be either (1, 3) or (1, 2, 3)), and therefore the statement is valid. I'm not sure how many nodes are in that "as far into the grammar as you have to", but each change is trivial; it's just a bit tedious to walk the whole graph, and since I'm -1 on the proposal, I'm not going to do it. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IUDJE4G6XWODP7TPOKZOKJUHIDTMCU2X/ Code of Conduct: http://python.org/psf/codeofconduct/