Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #63014 > unrolled thread

Re: Ifs and assignments

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Ifs and assignments Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-02 19:45 -0500
    Re: Ifs and assignments Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-03 14:33 +1100
      Re: Ifs and assignments Chris Angelico <rosuav@gmail.com> - 2014-01-03 14:49 +1100
        Re: Ifs and assignments Roy Smith <roy@panix.com> - 2014-01-02 23:14 -0500
          Re: Ifs and assignments Chris Angelico <rosuav@gmail.com> - 2014-01-03 15:25 +1100
          Re: Ifs and assignments Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-03 04:29 +0000
        Re: Ifs and assignments Duncan Booth <duncan.booth@invalid.invalid> - 2014-01-03 15:46 +0000
      Re: Ifs and assignments Chris Angelico <rosuav@gmail.com> - 2014-01-03 14:55 +1100
        Re: Ifs and assignments Roy Smith <roy@panix.com> - 2014-01-02 23:00 -0500
          Re: Ifs and assignments Chris Angelico <rosuav@gmail.com> - 2014-01-03 15:08 +1100

#63014 — Re: Ifs and assignments

On Thu, 02 Jan 2014 17:20:54 +0000, John Allsup <pydev@allsup.co> declaimed
the following:

>Hi,
>
>This is my debut on this list.
>
>In many languages, such as C, one can use assignments in conditionals 
>and expressions.  The most common, and useful case turns up when you 

	Really? You can't do it in FORTRAN, BASIC, COBOL, Pascal, Ada...

	C, C++, Java, C# are all based on the same core syntax. For all
effective purposes, they are the same as grouping M$ Visual BASIC,
GW-BASIC, Kemeny&Kurtz TrueBASIC as "most languages, such as BASIC"... 

>have if/else if/else if/else constructs.  Consider the following 
>non-working pseudoPython.
>
>import re
>r1 = re.compile("hello (\d)")
>r2 = re.compile("world([!?])")
>
>w = "hello world!"
>
	matcher = [ (r1, handleMatch1), (r2, handleMatch2) ]

>if m = r1.search(w):
>	handleMatch1(m)
>elif m = r2.search(w):
>	handleMatch2(m)
>else:
>	print("No match")
>
	for r, h in matcher:
		m = r.search(w)
		if m:
			h(m)
			break
	else:
		print ("no match")

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [next] | [standalone]

#63021

Dennis Lee Bieber wrote:

> On Thu, 02 Jan 2014 17:20:54 +0000, John Allsup <pydev@allsup.co>
> declaimed the following:

>>In many languages, such as C, one can use assignments in conditionals
>>and expressions.  The most common, and useful case turns up when you
> 
> Really? You can't do it in FORTRAN, BASIC, COBOL, Pascal, Ada...
> 
> C, C++, Java, C# are all based on the same core syntax. For all
> effective purposes, they are the same as grouping M$ Visual BASIC,
> GW-BASIC, Kemeny&Kurtz TrueBASIC as "most languages, such as BASIC"...


Thank you for pointing this out! Far too many people imagine that C and the
C-inspired languages make up the entire universe of programming.

But having said that, features should be judged on their merit, not on
whether they are familiar to Ada/Lisp/C/Algol/... programmers. (Although
familiarity is one factor out of many which should be considered.)

Personally, I find it hard to care about assignment as an expression. I find
the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
== instead of = or visa versa:

if m = re.match(pattern, text):
    ...

Using "as" is slightly better:

if re.match(pattern, text) as m:
    ...

but I don't think it's sufficiently useful for me to get excited about it.

However, I don't think we should treat this as specific to if statements:

    for i, obj in enumerate(alist + blist + clist as items):
        items[i] = process(obj)


Is that really better than this?

    items = alist + blist + clist
    for i, obj in enumerate(items):
        items[i] = process(obj)



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63023

On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> However, I don't think we should treat this as specific to if statements:
>
>     for i, obj in enumerate(alist + blist + clist as items):
>         items[i] = process(obj)
>
>
> Is that really better than this?
>
>     items = alist + blist + clist
>     for i, obj in enumerate(items):
>         items[i] = process(obj)

It definitely shouldn't be specific to if statements, though I think
that's probably going to be the biggest use-case (chained if/elif
blocks). Maybe a for loop isn't the best other example, but I
frequently work with places where I want to call some function and
keep iterating with the result of that until it returns false:

while (var = func())
{
    ....
}

In Python, that gets a lot clunkier. The most popular way is to turn
it into an infinite loop:

while True:
    var = func()
    if not var: break
    ....

which is pretty much how the C version will compile down, most likely.
It feels like an assembly language solution. The point of a while loop
is to put its condition into the loop header - burying it inside the
indented block (at the same indentation level as most of the code)
conceals that, and this is a very simple and common condition. So this
is what I'd cite as a second use-case:

while func() as var:
    ....

And that definitely looks more readable.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63029

In article <mailman.4823.1388720985.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> while (var = func())
> {
>     ....
> }
> 
> In Python, that gets a lot clunkier. The most popular way is to turn
> it into an infinite loop:
> 
> while True:
>     var = func()
>     if not var: break
>     ....

Or turn it into a generator:

def funcinator():
   while True:
      var = func()
      if var:
         yield var
      else:
         break

for var in funcinator():
   ....

That certainly makes your mainline code cleaner, but it's a lot of crud 
when all you really wanted to write was:

while func() as var:
   ....

[toc] | [prev] | [next] | [standalone]

#63030

On Fri, Jan 3, 2014 at 3:14 PM, Roy Smith <roy@panix.com> wrote:
> Or turn it into a generator:
> That certainly makes your mainline code cleaner...

Cleaner perhaps, but not clearer. Instead of seeing the original
function (say, a database retrieve-next call), you see a wrapper and
have to go dig to find out what it's actually doing. Unless it's some
kind of generic handler, like:

def funcinator(func,*args):
   while True:
      var = func(*args)
      if var:
         yield var
      else:
         break

while funcinator(cur.getnext):
    ....

But even that would be problematic until it got so thoroughly
understood that it's like enumerate() - which is itself still not
perfect.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63032

On 03/01/2014 04:25, Chris Angelico wrote:
> On Fri, Jan 3, 2014 at 3:14 PM, Roy Smith <roy@panix.com> wrote:
>> Or turn it into a generator:
>> That certainly makes your mainline code cleaner...
>
> Cleaner perhaps, but not clearer. Instead of seeing the original
> function (say, a database retrieve-next call), you see a wrapper and
> have to go dig to find out what it's actually doing. Unless it's some
> kind of generic handler, like:
>
> def funcinator(func,*args):
>     while True:
>        var = func(*args)
>        if var:
>           yield var
>        else:
>           break
>
> while funcinator(cur.getnext):
>      ....
>
> But even that would be problematic until it got so thoroughly
> understood that it's like enumerate() - which is itself still not
> perfect.
>
> ChrisA
>

I find the above rather funcy :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63067

Chris Angelico <rosuav@gmail.com> wrote:

> Maybe a for loop isn't the best other example, but I
> frequently work with places where I want to call some function and
> keep iterating with the result of that until it returns false:
> 
> while (var = func())
> {
>     ....
> }
> 
> In Python, that gets a lot clunkier. The most popular way is to turn
> it into an infinite loop:
> 
> while True:
>     var = func()
>     if not var: break
>     ....
> 

My preferred way would be to write it as a `for` loop:

for var in iter(func, False):
   ...


Though you do have to be sure to get the sentinel value correct as it will 
only break for the expected terminal False, not for 0, "", or None.

-- 
Duncan Booth

[toc] | [prev] | [next] | [standalone]

#63024

On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Personally, I find it hard to care about assignment as an expression. I find
> the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
> == instead of = or visa versa:

Python has similar problems, though. It's inherent to the nature of
symbolic languages.

a = (1, 2, 3)
b = {1, 2, 3}

In many fonts, it's hard to tell one from the other without peering.
Do people decry set literal notation in favour of explicitly writing
the word "set"? No; and I think most of us agree that it's better to
have the symbols. At least with == vs = there's a length difference. I
don't think it's C's fault or problem that equality and assignment
look similar and can be used in the same places, any more than it's a
problem to have assignment and subtraction differ by only one stroke:

a - (1, 2, 3)

Is that confusingly similar to assignment?

ChrisA

[toc] | [prev] | [next] | [standalone]

#63026

In article <mailman.4824.1388721334.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Jan 3, 2014 at 2:33 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > Personally, I find it hard to care about assignment as an expression. I find
> > the obvious C-inspired syntax terrible, as it is too easy to mistakenly use
> > == instead of = or visa versa:
> 
> Python has similar problems, though. It's inherent to the nature of
> symbolic languages.
> 
> a = (1, 2, 3)
> b = {1, 2, 3}
> 
> In many fonts, it's hard to tell one from the other without peering.
> Do people decry set literal notation in favour of explicitly writing
> the word "set"? No; and I think most of us agree that it's better to
> have the symbols. At least with == vs = there's a length difference. I
> don't think it's C's fault or problem that equality and assignment
> look similar and can be used in the same places, any more than it's a
> problem to have assignment and subtraction differ by only one stroke:
> 
> a - (1, 2, 3)
> 
> Is that confusingly similar to assignment?
> 
> ChrisA

I do this all the time:

t0 = time.time()
[some code]
t1 = time.time()
dt = t1 = t0   # <-- spot the typo?

[toc] | [prev] | [next] | [standalone]

#63028

On Fri, Jan 3, 2014 at 3:00 PM, Roy Smith <roy@panix.com> wrote:
> I do this all the time:
>
> t0 = time.time()
> [some code]
> t1 = time.time()
> dt = t1 = t0   # <-- spot the typo?

Yep, I see that... now that it's pointed out as a typo. Without the
marker, I'd assume it's correct chained assignment, and only an
examination of the name (dt = delta t) hints otherwise.

ChrisA

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web