Testing conditions.

Discussion in 'Python' started by Jeremy Bowers, Feb 10, 2005.

  1. On Thu, 10 Feb 2005 05:38:54 +0000, Ray Gibbon wrote:
    > e.g. 2
    > | while new_data, environment = get_more_data(source):
    > | process_data(new_data, environment)
    >
    > is something I'm equally likely to want to do, but I can't express it's
    > meaning.


    I think we'd usually phrase that as

    for new_data, environment in data(source):
    process_data(new_data, environment)

    and if data(source) isn't already an iterator of one form or another (a
    list, a generator, etc.), you can easily write it to be one; most of the
    time it already is.

    I use while, but much, much more rarely than for, even for things I'd
    write as "while" in other languages, and the majority of the "while"s are
    infinite generators, e.g.:

    def counter():
    i = 0
    while True:
    yield i
    i += 1
     
    Jeremy Bowers, Feb 10, 2005
    #1
    1. Advertising

  2. Jeremy Bowers

    Ray Gibbon Guest

    Testing conditions.

    Common scenario. Old programmer, new to Python, love it, but still
    hankering after some of my old ways.

    Of all of it's 'new to me' features, I appear to be enjoying 'no
    declarations' and mixing types with abandon. In particular I find myself
    writing functions which return whatever might be useful in whatever type
    seems appropriate, I'm really attracted to this, it works like magic.

    BUT, every time the result of a fuction hits a 'while' or 'if' the magic
    stops. If I want the result and I want to test it I have to do an
    assignment and test separately. It grates every time I come across this,
    and it seems obvious what I'm hankering for.

    I *know* this has been gone over and over and over...
    This is NOT another request for statements to be accepted as expressions for
    two reasons:-
    1. I've seen enough arguments on the subject where I've found myself firmly
    on the anti change side.
    2. I now realise that it might scratch the itch, but it would not cure it.

    e.g. 1
    | while new_data = get_more_data(source):
    | process_data(new_data)

    is obviously the sort of thing I'm missing, but it is not a general solution
    because :-

    e.g. 2
    | while new_data, environment = get_more_data(source):
    | process_data(new_data, environment)

    is something I'm equally likely to want to do, but I can't express it's
    meaning.

    Before I resign myself to the inevitable, 'that's the way it is - get used
    to it', I'd just like to scratch it once. But, before I try walking on very
    thin ice, I want to ask whether there are expectations of some future
    changes which address these issues?

    I note PEP 3000 is silent on this matter, and PEP 315, though related, is
    not relevant.

    Ray.
     
    Ray Gibbon, Feb 10, 2005
    #2
    1. Advertising

  3. Jeremy Bowers

    Terry Reedy Guest

    "Ray Gibbon" <> wrote in message
    news:cues7q$mg7$...
    > e.g. 1
    > | while new_data = get_more_data(source):
    > | process_data(new_data)
    >
    > is obviously the sort of thing I'm missing, but it is not a general
    > solution
    > because :-
    >
    > e.g. 2
    > | while new_data, environment = get_more_data(source):
    > | process_data(new_data, environment)
    >
    > is something I'm equally likely to want to do, but I can't express it's
    > meaning.


    The other problem with while loops, even if assignment were allowed, is
    that the loop stops on any null (False) value. So you soon would need to
    have the assignment buried within a comparison expression, as in C.

    > Before I resign myself to the inevitable, 'that's the way it is - get
    > used
    > to it', I'd just like to scratch it once. But, before I try walking on
    > very
    > thin ice, I want to ask whether there are expectations of some future
    > changes which address these issues?


    As Jeremy already implicitly pointed out, for loops already address these
    issues by combining assignment and a stop test, with the stop test being
    for a StopIteration exception rather than a null value. Separating data
    generation and validation from data processing is much cleaner.

    Terry J. Reedy
     
    Terry Reedy, Feb 10, 2005
    #3
  4. Ray Gibbon wrote:

    > This is NOT another request for statements to be accepted as expressions for
    > two reasons:-
    > 1. I've seen enough arguments on the subject where I've found myself firmly
    > on the anti change side.
    > 2. I now realise that it might scratch the itch, but it would not cure it.
    >
    > e.g. 1
    > | while new_data = get_more_data(source):
    > | process_data(new_data)
    >
    > is obviously the sort of thing I'm missing, but it is not a general solution
    > because :-
    >
    > e.g. 2
    > | while new_data, environment = get_more_data(source):
    > | process_data(new_data, environment)
    >
    > is something I'm equally likely to want to do, but I can't express it's
    > meaning.


    that's spelled

    for new_data, environment in get_data(source):
    process_data(new_data, environment)

    in Python. if you have existing get_first_data and get_more_data
    functions, add a wrapper function:

    def get_data(source):
    data = get_first_data(source)
    while data:
    yield data
    data = get_more_data(source)

    </F>
     
    Fredrik Lundh, Feb 10, 2005
    #4
  5. Jeremy Bowers

    Nick Coghlan Guest

    Ray Gibbon wrote:
    > Before I resign myself to the inevitable, 'that's the way it is - get used
    > to it', I'd just like to scratch it once. But, before I try walking on very
    > thin ice, I want to ask whether there are expectations of some future
    > changes which address these issues?
    >
    > I note PEP 3000 is silent on this matter, and PEP 315, though related, is
    > not relevant.


    The nicest idea I've seen along these lines is:

    if <expr> as <name>:
    pass
    elif <expr> as <name>:
    pass
    else:
    pass

    and

    while <expr> as <name>:
    pass

    It's based on the idea of using 'as' to name caught exceptions in Python 3k
    (which is in turn based on the use of as for renaming in import statements)

    However, like allowing assignment, this approach breaks down as soon the thing
    you want bound and the condition you want to test aren't the same, and then you
    have to switch back to the 'bind before test' approach.

    Which means a general solution has to allow *three* parts, not two:

    1. A conditional expression

    And optionally:
    2. A subexpression to be named
    3. The name for the subexpression

    That is, something like:

    if <expr> using <expr> as <name>:
    pass
    elif <expr> using <expr> as <name>:
    pass
    else:
    pass

    and

    while <expr> using <expr> as <name>:
    pass

    (In the degenerate case where the condition is the thing we want named, it may
    be possible to make the 'using' clause optional. If not, then the first
    expression is simply <name>)

    But such a solution involves an entirely new keyword and there's the eternal
    question of whether the feature is needed *enough* to justify complicating the
    syntax. The while case isn't good justification, since such while loops can
    usually be converted to a generator function and a pair of for loops easily
    enough. if/elif is slightly more promising as a motivation - having to convert
    to nested if statements if you discover you need access to some part of the
    condition test is a pain and the nested if's are harder to read that if/elif.
    How common is that situation in reality, though? I can't think of a case where
    I've had to use more than one nested if statement due to the 'problem' of not
    being to do an embedded assignment.

    *shrug* The issue has never really bothered me in practice. Heck, I often don't
    use nested assignment even in C, since the buggers can be so damn hard to read.
    That's mainly due to the = vs == problem though :)

    Cheers,
    Nick.

    --
    Nick Coghlan | | Brisbane, Australia
    ---------------------------------------------------------------
    http://boredomandlaziness.skystorm.net
     
    Nick Coghlan, Feb 10, 2005
    #5
  6. Jeremy Bowers

    Ray Gibbon Guest

    > Testing conditions.
    >


    All replies - Spot on!

    Much appreciated, apology for delay.

    Ray.
     
    Ray Gibbon, Feb 13, 2005
    #6
    1. Advertising

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. Brian van den Broek
    Replies:
    3
    Views:
    870
    Jeremy Bowers
    Apr 3, 2005
  2. Brian van den Broek
    Replies:
    2
    Views:
    404
    Brian van den Broek
    Apr 5, 2005
  3. Chris

    Testing and Load Testing

    Chris, Mar 4, 2007, in forum: ASP .Net
    Replies:
    2
    Views:
    338
  4. John Maclean
    Replies:
    1
    Views:
    357
    Martin P. Hellwig
    Apr 13, 2010
  5. Avi
    Replies:
    0
    Views:
    507
Loading...

Share This Page