while expression feature proposal

[Cameron Simpson]

On 26Oct2012 18:26, Tim Chase <sed at thechases.com> wrote:
| On 10/26/12 17:03, Cameron Simpson wrote:
| > On 26Oct2012 09:10, Paul Rubin <no.email at nospam.invalid> wrote:
| > |      while (client.spop("profile_ids") as profile_id) is not None:
| > 
| > Now this pulls me from a -0 to a +0.5.
| > 
| > 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.
| 
| I really don't like undefined (or underdefined) specs.  If it was to
| be PEP'd out, I'd want to address as many edge cases as possible.

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 <cs at zip.com.au>

Everything should be made as simple as possible, but no simpler.
- Albert Einstein