while expression feature proposal

Cameron Simpson cs at zip.com.au
Wed Oct 24 18:26:56 EDT 2012


On 24Oct2012 16:54, Tim Chase <python.list at tim.thechases.com> wrote:
| On 10/24/12 16:34, Ian Kelly wrote:
| > On Wed, Oct 24, 2012 at 2:40 PM, Dan Loewenherz <dloewenherz at gmail.com> wrote:
| >> So I'm sure a lot of you have run into the following pattern. I use it
| >> all the time and it always has felt a bit awkward due to the duplicate
| >> variable assignment.
| >>
| >> VAR = EXPR
| >> while VAR:
| >>     BLOCK
| >>     VAR = EXPR
| > 
| > The idiomatic way to do this is:
| > 
| > while True:
| >     VAR = EXPR
| >     if not VAR:
| >         break
| >     BLOCK
| 
| It may be idiomatic, but that doesn't stop it from being pretty
| ugly.

Yes, but more flexible because it accomodates loops where the natural
place for the test is partway through the loop instead of right at the
top, which is quite common.

| I must say I really like the parity of Dan's
|   while EXPR as VAR:
|      BLOCK
| proposal with the "with" statement.

Well, it's nice. But usually EXPR will be a boolean. If you're inside
the loop you know it's true and don't need VAR. Of course, the glaring
counter example is things like regexp tests. I have a heap of code like
this:

  m = re_FUNKYPATTERN.match(test_string)
  if m:
    do stuff with the results of the match, using "m"

If I could write this as:

  if re_FUNKYPATTERN.match(test_string) as m:
    do stuff with the results of the match, using "m"

then some cascading parse decisions would feel a bit cleaner. Where I
current have this:

  m = re_CONSTRUCT1.match(line)
  if m:
    ... handle construct 1 ...
  else:
    m = re_CONSTRUCT2.match(line)
    if m:
      ... handle construct 2 ...
    else:
      m = re_CONSTRUCT3.match(line)

I could have this:

  if re_CONSTRUCT1.match(line) as m:
    ... handle construct 1 ...
  elif re_CONSTRUCT2.match(line) as m:
    ... handle construct 2 ...
  elif re_CONSTRUCT3.match(line) as m:

which is both more concise and also doesn't step inward.

But I'm still -0 on it, because it supplants the glaringly obvious:

  m = ...

assignment with the far less in your face:

  possibly-long-expr as m

and I think it would get quite heavily used, to the detriment of
assignment readability in general. At present the nature of most effects
is at the left. An assignment is obvious on the left, an if/with/while/etc
is visible at the left.

With statements and except statements have concrete use cases for the
"as" part that aren't doable without it, but the while/if...as form
can always be written in the current convention.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au>



More information about the Python-list mailing list