Path: csiph.com!usenet.pasdenom.info!news.albasani.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
To: python-list@python.org
From: Gelonida N <gelonida@gmail.com>
Subject: Re: attaching names to subexpressions
Date: Sat, 27 Oct 2012 15:03:38 +0200
References: <a533d812-480e-479b-9210-7097c2d70d73@a4g2000pbo.googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
In-Reply-To: <a533d812-480e-479b-9210-7097c2d70d73@a4g2000pbo.googlegroups.com>
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.2934.1351343030.27098.python-list@python.org>
Lines: 122
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:32274

On 10/27/2012 04:42 AM, Steve Howell wrote:
 > I have been reading the thread "while expression feature proposal,"
 > and one of the interesting outcomes of the thread is the idea that
 > Python could allow you to attach names to subexpressions, much like C
 > allows.  In C you can say something like this:
 >
 >    tax_next_year = (new_salary = salary * (1 + raise)) * tax_rate
 >
 > To avoid the "=" pitfall, folks have proposed something like this for
 > Python:
 >
 >    tax_next_year = ((salary * (1 + raise)) as new_salary) * tax_rate
 >    print new_salary, tax_next_year
 >
. . .
 >
 > If the problem statement is "How do I name subexpression?", then
 > Python already has a clear path--break your code up into multiple
 > lines.  I'm wondering where this simple solution really breaks down
 > from a readability perspective.  Perhaps with short-circuited boolean
 > expressions?
 >

For me two places where expression assignemts can be useful are while 
loops and sometimes elif statements.


While example
----------------

line = complex_exression
while line:
     do something with(line)
     line = complex_expression

violates clearly the DRY principle  and the risk to change one line but 
not the other is high.


The 'canonical way'
while True:
     line = complex_expression
     if not line:
         break
     do_something_with(line)

avoids this problem, but I was never really convinced about the
beauty / readbility of this construct.

One misses the exit condition of the while loop on the first glance.
In my opinion I shouldn't be obliged to read any of the indented lines
of the while statement on a first 'visual' pass through somebody elses 
code and still be able to see what the loop iterates through.


Following looks in my opinion nicer.

while complex_expression as line:
     do_something_with(line)

or the even more powerful suggestion:

while (complex_expression as line) is not None:
     do_something_with(line)


Elif Example:
--------------

value1 = expression1
if (value1):
    do_something
else:
     value2 = expression2
     if(value2):
         do_something_with(value2)
     else:
         value2 = expression3
         if(value3):
             do_something_with(value3)

Could be rewritten as

value1= expression1
if(value1):
     do_something_with(value1)
elif(expression2 as value2):
     do_something_with(value2)
elif(expression3 as value3):
     do_something_with(value3)



However in all other cases I really think using this new syntax would 
reduce readability andit would be better to just split the statement 
into two lines.

for while / elif statements splitting up is not possible without doing 
some further acrobatics, which render in my opinion the code less readable.


If the new syntax were adopted, then one open question
would be scoping.

value=expression
if(value):
     do_something_with(value)
elif(expression2 as value):
     do_something_with(value)
elif(expression3 as value):
     do_something_with(value)
print value # will value leak out of the elif statements or not

I never tried to use other 'as-variables' (e.g. from  'with' or 'except' 
statements) outside of their indented block,
so I never bothered to check how Python would react.