if regex.search(string) as match:
     process it

But with

def if_true(expr):
     if expr: yield expr

you can do

for match in if_true(regex.search(string)):
     process it

But the proposed if ... as ...: statment woulkd be more beautiful by far.

is equivalent to about 40 lines of code as given here
http://www.python.org/dev/peps/pep-0380/#formal-semantics

It took the developers several tries to first get a version that worked
and then to work out the exact details.

Yours does indeed return one random value which is guaranteed not to be
in selected.

Mine returns random values until the value is not in selected. I just
misread the intention behind the while loop...

1) "while EXPR as VAR" in no way says that EXPR must be a boolean value. In fact, a use case I've run into commonly in web development is popping from a redis set. E.g.

    client = StrictRedis()
    while True:
        profile_id = client.spop("profile_ids")
        if not profile_id:
            break
        print profile_id

In this case, profile_id is "None" when the loop breaks. It would be much more straightforward (and more Pythonic, IMO), to write:

    client = StrictRedis()
    while client.spop("profile_ids") as profile_id:
        print profile_id

2) Although not originally intended, I kind of like the "if" statement change proposed later in this thread. It certainly makes sense, since both while and if are "conditional" statements that are commonly followed by an assignment (or vice versa).

3) I don't think the use case I brought up is solved nicely by wrapping a function / lambda in a generator and using a for loop. E.g.

    def helper(f):
        value = f()
        if value:
            yield value

    for profile_id in helper(lambda: client.spop("profile_ids")):
        print profile_id

This works too, I guess

    def helper(f, *args, **kwargs):
        value = f(*args, **kwargs)
        if value:
            yield value

    for profile_id in helper(client.spop, "profile_ids"):
        print profile_id

Either way, it adds too much mental overhead. Every developer on a project has to now insert x lines of code before a for loop or import a helper method from some module, and do this every time this pattern reappears. It's not something I would want to do in one of my projects, since it makes things harder to understand. So all in all, it's a net negative from just doing things the canonical way (with the while / assignment pattern).

Why is everyone skirting around C-style assignment expressions as
though they're simultaneously anathema and the goal? :)

But seriously, this new syntax would probably enhance Python somewhat,
but you're going to end up with odd edge cases where it's just as
almost-there as current syntax is for what this will solve. Is it
worth doing half the job?

We also don't special case things like this just because x is an empty string. If this "while EXPR as VAR" thing were to move forward, we shouldn't treat the truth testing any differently than how we already do. IMO we should write our applications with the understanding that '' will return False and work with that.

Here's a workaround BTW. Just have that method return a tuple, and do the truth testing yourself if you feel it's necessary.

    while client.spop("profile_ids") as truthy, profile_id:
        if not truthy:
            break

        print profile_id

Here, client.spop returns a tuple, which will always returns true. We then extract the first element and run a truth test on it. The function we use is in charge of determining the truthiness.

The empty string is a perfectly good string and code that deals with
strings should handle the empty string properly, unless it knows the
string won't be empty.  Basic modularity principles say to avoid putting
such knowledge into more of the code than necessary.  

The conclusion is to not automatically convert the parameter to a bool.
However, if the "as" can be part of an expression as in Chris Angelico's
post, Chris's suggestion

     while (client.spop("profile_ids") as profile_id) is not None:
         print profile_id

looks good to me.

Now this pulls me from a -0 to a +0.5.

Instead of burdening the control constructs with further structure, make
"as" a binding operation for keeping intermediate results from expressions.

It will work anywhere an expression is allowed, and superficially
doesn't break stuff that exists if "as" has the lowest precedence.

Any doco would need to make it clear that no order of operation is
implied, so that this:

  x = 1
  y = (2 as x) + x

does not have a defined answer; might be 2, might be 3. Just like any
other function call with side effects.

Speaking for myself (of course!), I definitely prefer this to adding
"as" as a post expression struction on if/while/etc.

I'm not +1 because to my mind it still presents a way for
assignment/binding to not be glaringly obvious at the left hand side of
an expression.

It would probably mean folding the except/with "as" uses back into
expressions and out of the control-structural part of the grammar. I can't
see that that would actually break any existing code though - anyone else?

Cheers,
--
Cameron Simpson <c...@zip.com.au>

    client = StrictRedis()
    for profile_id in iter(lambda: client.spop("profile_ids"), None):
        pass

I would like a better iter(), rather than a better while loop. It is
irritating to pass in functions that take arguments, and it is
impossible to, say, pass in functions that should stop being iterated
over when they return _either_ a None or a, say, False.

    with foo() as bar: bar.baz()
    with (foo() as bar): bar.baz()

I don't understand why everyone is so attached to this "as" syntax.
It's confusing because it behaves subtly differently than how it works
in "with", and it puts the variable on the wrong side of the
assignment operator.

(I've always been partial to ":=", personally.)

  y = (2 as x) + (3 as x) + (4 as x)
  y = (2 as x) + 4 as x
  y = booleanish and (2 as x) or (4 as x)
  y = booleanish and 2 or 4 as x
  y = (2 as x) if booleanish else (3 as x)
  y = (2 as x) if booleanish else (3 as z)

regardless of how "$PEJORATIVE, that's a dumb thing to do!" it is.

I hate C for how underdefined a lot of corners are. ("amongst my
hatreds of C are such diverse elements as: underdefined corners, a
pitiful standard library, the ease of shooting yourself in the foot,
...")

http://docs.python.org/reference/expressions.html#evaluation-order

No. Separate _expressions_ are evaluated left to right.

So this:

  f(1), f(2)

calls "f(1)" first, then "f(2)". But this:

  f(1) + f(2)

need not do so. Counter-documentation welcomed, but the doco you cite
does not define an order for the second example above.

|
| >>> def set_(d, k, v):
| ...     d[k] = v
| ...     return v
| ...
| >>> d = {}
| >>> set_(d, 'x', 1)
| 1
| >>> set_(d, 'y', set_(d, 'x', 2) + d['x'])
| 4

That may just be a coincidence of implementation - there's no special
reason to change the evaluation order form the lexical order there, but
expression optimisers should have a free hand generally.

Cheers,
--
Cameron Simpson <c...@zip.com.au>

I was thinking more like this:

    for profile_id in iter(None)(client.spop, "profile_ids"):

or alternatively:

    for profile_id in iter(bool)(client.spop, "profile_ids"):

Or perhaps either as keyword arguments (which is the only reason I
curried iter).

The interesting case for in-place assignment is not here. This is a
trivial case. It's in cases like this:

    while True:
        x = foo(bar())
        if x is None: break
        if x % 2 == 0: break

        print x

Imagine doing that with iter. :)

    In the following lines, expressions will be evaluated in the
arithmetic order of their suffixes:
        ...
        expr1 + expr2 * (expr3 - expr4)

I sympathize with your concern, though. Order of evaluation is very
bitey, and it's better to be safe than sorry.

-1

I would not. Big time. One of the reasons C is so successful as a
lower level language is that by defining only what is needed to be
defined to make it _possible_ to get predictable and useful behaviour,
maximum flexibility is left for implementation to adapt to particular
environments as freely as possible.

Pinning down all the corner cases is in general a bad idea, IMO. Every
corner case you pin down is an early decision for inflexibility that may
later prove to be illfounded.

Specify what _needs_ to be specified to achieve the required effect.
And stay the hell away from things that only constraint outcomes while
not providing the required effect.

To take an obvious counter example: your stance would encourage defining
the iteration order of dictionary keys. To no good purpose, merely to
present definition of _all_ operations instead of just the necessary
operations.

| Such as
|   y = (2 as x) + (3 as x) + (4 as x)
|   y = (2 as x) + 4 as x

I would want these to be ambiguous, myself.

|   y = booleanish and (2 as x) or (4 as x)
|   y = booleanish and 2 or 4 as x
|   y = (2 as x) if booleanish else (3 as x)
|   y = (2 as x) if booleanish else (3 as z)

None of these is ambiguous. The second one could be harder to read and
want some brackets purely for clarity, but it is perfectly well defined
in outcome already.

| regardless of how "$PEJORATIVE, that's a dumb thing to do!" it is.

No, sometimes dumb things should remain bad ideas. Defining them to all
just makes them no longer obviously bad ideas, merely subtly bad ideas.
And subtly bad ideas are worse!

| I hate C for how underdefined a lot of corners are. ("amongst my
| hatreds of C are such diverse elements as: underdefined corners, a
| pitiful standard library, the ease of shooting yourself in the foot,
| ...")

The C standard library was pretty good for when it came out. And the higher
up the available facilities tree you go the more choices there are about
how something should be done. C is still one of my favourite languages
in its domain, though I haven't used it much for several years.

If you're uncomfortable with C, try to stay away from it. (I try to stay
away from C++ and its bretheren for similar reasons.)

| > I'm not +1 because to my mind it still presents a way for
| > assignment/binding to not be glaringly obvious at the left hand side of
| > an expression.
|
| I think this is why I like it in the "while" (and could be twisted
| into accepting it for "if") because it also introduces an
| implied/actual scope for which the variable is intended.

A conceptual scope, sure. Presumably not a real one in Python...

| In an
| arbitrary evaluation/assignment, it's much easier to lose the
| "definition" nature of it at the top of a block.

I'm not sure I agree here. Code example?

Cheers,
--
Cameron Simpson <c...@zip.com.au>