Re: while expression feature proposal

Discussion in 'Python' started by Cameron Simpson, Oct 27, 2012.

  1. On 26Oct2012 18:26, Tim Chase <> wrote:
    | On 10/26/12 17:03, Cameron Simpson wrote:
    | > On 26Oct2012 09:10, Paul Rubin <> 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

    | 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?

    Cameron Simpson <>

    Everything should be made as simple as possible, but no simpler.
    - Albert Einstein
    Cameron Simpson, Oct 27, 2012
    1. Advertisements

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dan Loewenherz

    while expression feature proposal

    Dan Loewenherz, Oct 24, 2012, in forum: Python
    Paul Rubin
    Oct 24, 2012
  2. Ian Kelly
    Ian Kelly
    Oct 24, 2012
  3. Tim Chase
    Tim Chase
    Oct 24, 2012
  4. Cameron Simpson

    Re: while expression feature proposal

    Cameron Simpson, Oct 24, 2012, in forum: Python
    Thomas Rachel
    Oct 25, 2012
  5. Chris Angelico

    Re: while expression feature proposal

    Chris Angelico, Oct 24, 2012, in forum: Python
    Chris Angelico
    Oct 24, 2012