Re: Cleaning up conditionals
Steve D'Aprano writes: > On Sun, 1 Jan 2017 02:58 pm, Deborah Swanson wrote: > >>> It's possible to select either l1 or l2 using an expression, >>> and then subscript that with [v]. However, this does not >>> usually make for readable code, so I don't recommend it. >>> >>> (l1 if whatever else l2)[v] = new_value >>> >>> ChrisA >> >> I'm not sure I understand what you did here, at least not well enough >> to try it. > > > The evolution of a Python programmer :-) > > > (1) Step One: the naive code. > > if condition: > l1[v] = new_value > else: > l2[v] = new_value > > > (2) Step Two: add a temporary variable to avoid repeating the > assignment > > if condition: > temp = l1 > else: > temp = l2 > temp[v] = new_value > > > (3) Step Three: change the if...else statement to an expression > > temp = l1 if condition else l2 > temp[v] = new_value > > > (4) Step Four: no need for the temporary variable > > (l1 if condition else l2)[v] = new_value (l1 if bool(l1[v]) < bool(l2[v]) else l2 if bool(l1[v]) > bool(l2[v]) else l1)[v] = (l2 if bool(l1[v]) < bool(l2[v]) else l1 if bool(l1[v]) > bool(l2[v]) else l1)[v] Merry new year :) -- https://mail.python.org/mailman/listinfo/python-list
RE: Cleaning up conditionals
Sorry guys. I've read all your responses and I kind of get their general drift, but I'm about four sheets to the wind right now, and no way would I make it more than a step or two in playing around with these things and trying to get my head around them before it would all descend into a cacaphony of gibberish. Python really is a thing of beauty in a class all its own. I've been doing computers since 1972. I started out doing machine code on IBM's 7090 octal machine, then I stepped up to assembler on the hexadecimal IBM 360/40, a mainframe that needed a machine room the size of two classrooms to house it and all its peripherals. (Disk drives were the size of huge round birthday cakes, tape drives were each housed in 4' x 4' cabinets, and the printers had to go out in the hallway because they couldn't even fit in the same room with the computer.) The first high level language I stepped up to was PL/1, a real behemoth of its time, a one-foot-in-front-of-the-other procedural languaage from its insides out, and a full set of all its manuals filled a small library. Funny though, for all its "primitivity" compared to modern languages, we did artificial intelligence, symbolic calculus (no numbers, just complex integrals and differentials of function names, with x, y and z for arguments) and weather modelling with it. And I've learned smatterings of Java, C and C++, but nowhere have I seen the kinds of magic that can be done with python. I've been exposed to applying functions to a list of values, so I fully believe that what you present is valid python and it works. I just don't fully understand how and will have to work with it. So, in the morning I'll scrape my braincells together and work with what you've given me, and see if I can understand it and make your examples work. Well worth the detour from finding the perfect place to move to (a project that has become a little less urgent due to recent events). So stay tuned. I'm not ignoring you, I just need a good night's sleep and then maybe a good long while before I have anything to show for doing anything with this, or even intelligent questions. Thank you all in advance, I'm expecting to learn a lot from this little exercise. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cleaning up conditionals
On Sunday, January 1, 2017 at 3:39:14 PM UTC+5:30, Deborah Swanson wrote: > Sorry guys. I've read all your responses and I kind of get their general > drift, but I'm about four sheets to the wind right now, and no way would > I make it more than a step or two in playing around with these things > and trying to get my head around them before it would all descend into a > cacaphony of gibberish. Its true that in most programming languages one is likely to see, a conditional (if) statement is likely harder to grok than a conditional expression ie if the expression is allowed at all!! Just as recursion is supposedly harder than repetition, List comprehensions harder than for-loops etc etc This is true culturally and historically but not necessarily. >From the more conceptual viewpoint they are duals; see table at http://blog.languager.org/2016/01/primacy.html#expstat Of course if one has grown up with assignment (and even more so the print statement) being (imagined to be) easy and natural and obvious, this logically unnecessary but culturally inevitable sense of difficulty will be there... unfortunately. tl;dr Above is unlikely to help reduce the confusion. The essential ideas behind the jargon called 'functional programming' would go a good way towards that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Cleaning up conditionals
On Sunday, January 1, 2017 at 7:51:12 PM UTC+5:30, Rustom Mody wrote: > On Sunday, January 1, 2017 at 3:39:14 PM UTC+5:30, Deborah Swanson wrote: > > Sorry guys. I've read all your responses and I kind of get their general > > drift, but I'm about four sheets to the wind right now, and no way would > > I make it more than a step or two in playing around with these things > > and trying to get my head around them before it would all descend into a > > cacaphony of gibberish. > > Its true that in most programming languages one is likely to see, > a conditional (if) statement is likely harder to grok than a conditional > expression ie if the expression is allowed at all!! Er... Meant the other way round! -- https://mail.python.org/mailman/listinfo/python-list
Re: learning and experimenting python.
On 2016-12-31, Ian Kelly wrote: > On Dec 31, 2016 3:12 AM, wrote: > > That's true. > > Please include quoted context in your replies. I have no idea who or what > you're responding to. I'd just like to thank everybody for replying to einstein1410's posts so that those of us who have plonked posts from googlegroups don't miss out on his/her valuable contributions. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
RE: Cleaning up conditionals
Steve D'Aprano wrote > Sent: Saturday, December 31, 2016 10:25 PM > > On Sun, 1 Jan 2017 02:58 pm, Deborah Swanson wrote: > > >> It's possible to select either l1 or l2 using an > expression, and then > >> subscript that with [v]. However, this does not usually make for > >> readable code, so I don't recommend it. > >> > >> (l1 if whatever else l2)[v] = new_value > >> > >> ChrisA > > > > I'm not sure I understand what you did here, at least not > well enough > > to try it. > > > The evolution of a Python programmer :-) ;) > (1) Step One: the naive code. > > if condition: > l1[v] = new_value > else: > l2[v] = new_value > > > (2) Step Two: add a temporary variable to avoid repeating the > assignment > > if condition: > temp = l1 > else: > temp = l2 > temp[v] = new_value > > > (3) Step Three: change the if...else statement to an expression > > temp = l1 if condition else l2 > temp[v] = new_value > > > (4) Step Four: no need for the temporary variable > > (l1 if condition else l2)[v] = new_value > > > > > > -- > Steve > "Cheer up," they said, "things could be worse." So I cheered > up, and sure enough, things got worse. This is a very nice explanation of why Chris' statement is valid python and I completely understand it, though I didn't see how it worked when I wrote the message you're quoting. Unfortunately this isn't the part that still gives me trouble. The real troublemaker here for me, is what should new_value be defined to be? It will be either l1[v] or l2[v], depending on which one is non-empty. But I still don't see any way this terniary assigns the correct value to the correct field. If we back up to your Step One, it's clear that this dilemma is present from the get-go. (1) Step One: the naive code. if condition: l1[v] = new_value else: l2[v] = new_value Here the assumption is that new_value is the same for both if and else. But it isn't. Here's the actual desired outcome: if condition: l1[v] = l2[v] else: l2[v] = l1[v] That's why I've been saying that (l1 if whatever else l2)[v] = new_value works beautifully if you are computing a value, but it doesn't work at all if you're selecting a row to copy the field value from the other row to. -- https://mail.python.org/mailman/listinfo/python-list
RE: Cleaning up conditionals
Chris Angelico wrote on Saturday, December 31, 2016 9:39 PM > > On Sun, Jan 1, 2017 at 2:58 PM, Deborah Swanson > wrote: > > I'm not sure I understand what you did here, at least not > well enough > > to try it. > > > > What conditional can I do between the 2 rows of listings (the list > > names l1 and l2) that will give me which row has the value to copy > > from and which one is empty? I don't see how that can happen if you > > don't give the subscript [v] to each of l1 and l2, at a minimum. > > Unless python will distribute the [v] inside the preceding > > conditional? Amazing, if true, but then we still need what the > > conditional is. > > > > And what is new_value? It could be either l1[v] or l2[v], > depending on > > which one is not empty, and I don't see how the answer > magically pops > > into it. Not saying that it doesn't, but what should I > call new_value > > in the real estate listings example I want to use it in? > There are no > > new values in this situation, only values that need to be > copied into > > their empty counterparts in the other row. (It may or may > not help to > > read the synopsis of what I'm doing that I wrote up in my > last post to > > Peter Otten.) > > Start with this simple statement: > > foo[2] = "spam" > > Obviously this will subscript 'foo' with 2 and set that to > the string "spam". Easy. But instead of the word 'foo', we > could use any expression at all. > > def return_foo(): > return foo > > return_foo()[2] = "spam" > > This is a little more surprising, but it does work. > > And if you can use a function call to provide the list, you > can use anything else - even a conditional expression. > > (foo if True else [])[2] = "spam" > > It's perfectly legal, but I do NOT recommend it :) > > ChrisA I see what you're doing here and I have applied functions to values and variables before, so I know it's legal and that it works. Thanks for giving me this other way that the same principle can be used with conditionals. I know I keep repeating myself, but aside from the advisability (or not) of using this form, the real problem is that "spam" will only be the right answer in one of the two cases. The job of this conditional is to choose which value to put into which field. -- https://mail.python.org/mailman/listinfo/python-list
RE: Cleaning up conditionals
> -Original Message- > From: Python-list > [mailto:python-list-bounces+python=deborahswanson.net@python.o > rg] On Behalf Of Jussi Piitulainen > Sent: Saturday, December 31, 2016 11:45 PM > To: python-list@python.org > Subject: Re: Cleaning up conditionals > Importance: High > > > Deborah Swanson writes: > > > Jussi Piitulainen wrote: > >> Sent: Saturday, December 31, 2016 8:30 AM > >> Deborah Swanson writes: > >> > >> > Is it possible to use some version of the "a = expression1 if > >> > condition else expression2" syntax with an elif? And for > >> > expression1 and expression2 to be single statements? That's the > >> > kind of shortcutting I'd like to do, and it seems like > python might > >> > be able to do something like this. > >> > >> I missed this question when I read the thread earlier. The > >> answer is simply to make expression2 be another conditional > >> expression. I tend to write the whole chain in parentheses. > >> This allows multi-line layouts like the following alternatives: > >> > >> a = ( first if len(first) > 0 > >> else second if len(second) > 0 > >> else make_stuff_up() ) > >> > >> a = ( first if len(first) > 0 else > >> second if len(second) > 0 else > >> make_stuff_up() ) > >> > >> Expression1 and expression2 cannot be statements. Python > >> makes a formal distinction between statements that have an > >> effect and expressions that have a value. All components of a > >> conditional expression must be expressions. A function call > >> can behave either way but I think it good style that the > >> calls in expresions return values. > > > > While I'm sure these terniaries will be useful for future > problems, I > > couldn't make the second one work for my current problem. > > (Note that those two things are just different layouts for > the exact same conditional expression.) > > > I got as far as: > > > > a = l1[v] if len(l1[v] > 0 else > > l2[v] if len(l2[v] > 0 else > > (Parentheses needed, otherwise the first line is expected to > be a whole statement and then the unfinished expression in it > is considered > malformed.) Thanks, I missed that. (Never ran the code because I couldn't finish it.) > > And didn't finish it because I couldn't see what a should > be. I want > > it to be l2[v] if the first clause is true, and l1[v] if > the second. > > If I was computing a value, this would work beautifully, > but I don't > > see how it can if I'm choosing a list element to assign to. Maybe I > > just can't see it. > > Do you here mean condition when you say clause? Then, if the > first condition is true, any other condition is not > considered at all. When you come to the final else-branch, > you know that all conditions in the chain were false. This is fine, in general we wouldn't know if either l1[v] or l2[v] are non-empty, and it would be possible that both are empty. But this function is only called if they're not equal, which means one of them could be empty, or that the two fields are both non-empty and different from each other (my second test). So I had two problems implementing this code. The first one was that the final else was a dead end and I didn't see what to replace it with (though I can see now what it should be). But the biggest problem is what a is. It should be either the location l1[v] or the location l2[v], but by making it a scalar, a is not in either row. It's just a disconnected variable, so the statement doesn't assign anything to a field in either row. > I thought you originally wanted to keep l1[v] if it was > non-empty, which is what the code here says, but this time > your prose seems different. Anyhow, since you want a value > when all conditions in the chain of conditions are false, you > want a value to use when the field is empty in both records. > To change nothing, store the old empty value back; or you can > supply your own default here. > > With your particular conditions of non-emptiness, which is > taken to be truth, you can achieve variations of this result > with any of the following statements: > > w = ( l1[v] if len(l1[v]) > 0 else > l2[v] if len(l2[v]) > 0 else > l1[v] ) > > x = l1[v] if l1[v] else l2[v] if l2[v] else l1[v] > > y = l1[v] or l2[v] or l1[v] > > z = l1[v] or l2[v] > > The last one, which I originally suggested (and still prefer > when otherwise appropriate), is subtly different from the > others. That difference should be irrelevant. I agree, if the goal was to capture one of the field values in a scalar value. Maybe it would help if I give a couple rows of (made up) data to show what I mean (first row is field titles): ..Description DateState/coKind Notes l1 2 br, Elk Plains12-26 WA/pi house garage, w/d l2 2 br, Elk Plains12-29 In this case, I want to copy the values from l1 to l2. Or I could have, say, if I didn't see the one on
Re: Cleaning up conditionals
On Sat, 31 Dec 2016 14:35:46 -0800, "Deborah Swanson" declaimed the following: if len(l1[v]) == 0 and len(l2[v]) != 0: l1[v] = l2[v] elif len(l2[v]) == 0 and len(l1[v]) != 0: l2[v] = l1[v] elif l1[v] != l2[v]: ret += ", " + labels[v] + " diff" if len(ret) > 0 else labels[v] + " diff" There are a couple of things I would probably do with this: 1. Drop the len() calls and just test the lists directly. 2. Eliminate some redundant indexing operations. l1v = l1[v] l2v = l2[v] if l2v and not l1v: l1[v] = l2v elif l1v and not l2v: l2[v] = l1v elif l1v != l2v: ret += ", " + labels[v] + " diff" if len(ret) > 0 else labels[v] + " diff" Jussi Piitulainen wrote: > (l1 if bool(l1[v]) < bool(l2[v]) else > l2 if bool(l1[v]) > bool(l2[v]) else > l1)[v] = (l2 if bool(l1[v]) < bool(l2[v]) else >l1 if bool(l1[v]) > bool(l2[v]) else >l1)[v] > If you're aiming for readability, that's *not* the way to go! Not every 7-line function needs to be written on one line. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Cleaning up conditionals
On 01/01/2017 14:32, Rustom Mody wrote: On Sunday, January 1, 2017 at 7:51:12 PM UTC+5:30, Rustom Mody wrote: On Sunday, January 1, 2017 at 3:39:14 PM UTC+5:30, Deborah Swanson wrote: Sorry guys. I've read all your responses and I kind of get their general drift, but I'm about four sheets to the wind right now, and no way would I make it more than a step or two in playing around with these things and trying to get my head around them before it would all descend into a cacaphony of gibberish. Its true that in most programming languages one is likely to see, a conditional (if) statement is likely harder to grok than a conditional expression ie if the expression is allowed at all!! Er... Meant the other way round! Python's version is certainly a little harder to understand! What is it again: X if C else Y ? Here, if C is false, then only Y is evaluated, even though the first thing encountered is X! More than a little unintuitive. -- Bartc -- https://mail.python.org/mailman/listinfo/python-list
New re feature in 3.6: local flags and example use
The re module defines several flags that affect the compilation of a pattern string. For instance, re.I == re.IGNORECASE results in case-insensitive matching. But what if you want part of a pattern to be case sensitive and part not? For instance, the IDLE colorizer needs to match keywords and builtin names with their exact case: 'if' is a keywork, 'If', 'iF', and 'IF' are not. However, case does not matter string prefixes: 'fr', 'fR', 'Fr', and 'FR' are all the same to the tokenizer. So the string prefix part of the colorize pattern was recently upgraded to r"(\br|R|u|U|f|F|fr|Fr|fR|FR|rf|rF|Rf|RF|b|B|br|Br|bR|BR|rb|rB|Rb|RB)?" 3.6 added syntax for 'local flags'. ''' (?imsx-imsx:...) (Zero or more letters from the set 'i', 'm', 's', 'x', optionally followed by '-' followed by one or more letters from the same set.) The letters set or removes the corresponding flags: re.I (ignore case), re.M (multi-line), re.S (dot matches all), and re.X (verbose), for the part of the expression. (The flags are described in Module Contents.) ''' Here is the replacement for the above, curtesy of Serhiy Storchaka. r"(?i:\br|u|f|fr|rf|b|br|rb)?" -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
RE: Cleaning up conditionals
Dennis Lee Bieber wrote, on Sunday, January 01, 2017 6:07 PM > > On Sun, 1 Jan 2017 15:50:25 -0800, "Deborah Swanson" > declaimed the following: > > >Maybe it would help if I give a couple rows of (made up) > data to show > >what I mean (first row is field titles): > > > >..DescriptionDateState/coKind > >Notes > >l1 2 br, Elk Plains12-26 WA/pi house > >garage, w/d > >l2 2 br, Elk Plains12-29 > > > >In this case, I want to copy the values from l1 to l2. > > > >Or I could have, say, if I didn't see the one on 12-26 until after > >12-29: > >l1 2 br, Elk Plains12-26 > >l2 2 br, Elk Plains12-29 WA/pi house > >garage, w/d > > > >In this case, I want to copy the values from l2 to l1. > > > > And what happens if the data (where ever you get it > from to be in one > file) looks like > > l12 br, Elk Plains12-26 WA/pi > l22 br, Elk Plains12-29 > house garage, w/d > > As I understand your logic, you intend to make the two > entries identical EXCEPT for the DATE. What purpose does this > duplication serve? Or, put another way -- why is preserving > distinctive dates important while everything else is subject > to being blended. Yes, that's exactly what I'm doing in this bit of code, making all the listings that are identical except for the date be identical except for the date. You may or may not have tried this approach to finding the ideal house, but this is my third house hunt, using essentially the same approach, but in a different language each time. (Python is by far the best version. A dictionary with city names as keys, and several data items as values has literally cut the task in half.) The usefulness of keeping track of these duplicate listings is history of the rental being offered. In a real estate market that's on fire like we have here in the Pacific NW, any house that's relisted more than a couple times has something wrong with it or it would have been snatched up, or it's way out in the boonies. In any event, if I do decide to look at it, my bargaining position is improved by knowing that they've been trying to rent it for a long friggin time. When I find a new one that looks promising, I may reject it if I see that it's been on the market a long time (and I have another bit of code that tells me that instantly). You can design your project any way you want to! > I still get this feeling you should have master file, > regardless of whether fields are empty, and treat subsequent > data as updates to the master file -- not as some confusing > single file with some sort of duplicate contents. > -- > Wulfraed Dennis Lee Bieber AF6VN > wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/ You're certainly entitled to your opinion, but my method is time-tested for my purposes. -- https://mail.python.org/mailman/listinfo/python-list
Re: New re feature in 3.6: local flags and example use
On Sun, Jan 1, 2017 at 8:25 PM, Terry Reedy wrote: \> 3.6 added syntax for 'local flags'. > ''' > (?imsx-imsx:...) > > (Zero or more letters from the set 'i', 'm', 's', 'x', optionally > followed by '-' followed by one or more letters from the same set.) The > letters set or removes the corresponding flags: re.I (ignore case), re.M > (multi-line), re.S (dot matches all), and re.X (verbose), for the part of > the expression. (The flags are described in Module Contents.) > ''' > Here is the replacement for the above, curtesy of Serhiy Storchaka. > > r"(?i:\br|u|f|fr|rf|b|br|rb)?" What is the difference between the letters before the hyphen and those after? I guess that placing the letter before means to set the flag and after means to unset it, but it's not clear from the documentation. -- https://mail.python.org/mailman/listinfo/python-list
Re: learning and experimenting python.
On Sun, 01 Jan 2017 10:41:22 -0800, einstein1410 wrote: > What contribution I had made especially valuable? Ask your mommy what sarcasm means. -- GNU/Linux user #557453 The cow died so I don't need your bull! -- https://mail.python.org/mailman/listinfo/python-list
Re: learning and experimenting python.
On Sun, Jan 1, 2017 at 11:30 AM, Grant Edwards wrote: > On 2016-12-31, Ian Kelly wrote: >> On Dec 31, 2016 3:12 AM, wrote: >> >> That's true. >> >> Please include quoted context in your replies. I have no idea who or what >> you're responding to. > > I'd just like to thank everybody for replying to einstein1410's posts > so that those of us who have plonked posts from googlegroups don't > miss out on his/her valuable contributions. If you want your own decision to cease interacting with him to be forced on everybody here then I suggest you petition the group admins to ban him rather than merely plonk him yourself. Since they're unlikely to do that however, I suppose you'll just have to find a way to cope, much as others of us have done when occasionally exposed to quoted material by perennial trolls such as Ranting Rick. For a starter, since this is the only thread he's posted in, you could mute it. -- https://mail.python.org/mailman/listinfo/python-list
Re: learning and experimenting python.
On Mon, Jan 2, 2017 at 12:15 AM, Ian Kelly wrote: > Since they're unlikely to do that however, Then again, I see that einstein1410 made a couple of rather aggressive posts 11 hours ago that haven't made it to my email, so maybe he did manage to get himself banned. -- https://mail.python.org/mailman/listinfo/python-list
Re: learning and experimenting python.
On 02/01/17 06:40, Ian Kelly wrote: On Mon, Jan 2, 2017 at 12:15 AM, Ian Kelly wrote: Since they're unlikely to do that however, Then again, I see that einstein1410 made a couple of rather aggressive posts 11 hours ago that haven't made it to my email, so maybe he did manage to get himself banned. We are holding (and, so far, dropping) posts from that address. FWIW I concur with an earlier poster that the person in question is simply ill-informed rather than deliberately provocative. I have sympathy with their initial ignorance; less with their apparent inability to learn from other people's well-intentioned comments. Probably best to let the thing drop rather than let it escalate into a sniping war. If anyone reading this knows the poster in person, please help them to see how their posts have come across and whey they received the reaction they did. TJG -- https://mail.python.org/mailman/listinfo/python-list
