Re: Testing conditions.
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 | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing conditions.
On Thu, 10 Feb 2005 05:38:54 +, 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 whiles are infinite generators, e.g.: def counter(): i = 0 while True: yield i i += 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing conditions.
Ray Gibbon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Testing conditions.
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 -- http://mail.python.org/mailman/listinfo/python-list
