Testing conditions.

[Ray Gibbon]

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(s ource):
| process_data(ne w_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(s ource):
| process_data(ne w_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.

[Jeremy Bowers]

Re: Testing conditions.

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

I think we'd usually phrase that as

for new_data, environment in data(source):
process_data(ne w_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

[Terry Reedy]

Re: Testing conditions.


"Ray Gibbon" <ray@rgibbon.fr eeserve.co.uk> wrote in message
news:cues7q$mg7 $1@news7.svr.po l.co.uk...[color=blue]
> e.g. 1
> | while new_data = get_more_data(s ource):
> | process_data(ne w_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(s ource):
> | process_data(ne w_data, environment)
>
> is something I'm equally likely to want to do, but I can't express it's
> meaning.[/color]

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.
[color=blue]
> 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?[/color]

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

[Fredrik Lundh]

Re: Testing conditions.

Ray Gibbon wrote:
[color=blue]
> 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(s ource):
> | process_data(ne w_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(s ource):
> | process_data(ne w_data, environment)
>
> is something I'm equally likely to want to do, but I can't express it's
> meaning.[/color]

that's spelled

for new_data, environment in get_data(source ):
process_data(ne w_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(s ource)

</F>

[Nick Coghlan]

Re: Testing conditions.

Ray Gibbon wrote:[color=blue]
> 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.[/color]

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 | ncoghlan@email. com | Brisbane, Australia
---------------------------------------------------------------

http://boredomandlaziness.skystorm.net

[Ray Gibbon]

Re: Testing conditions.

> Testing conditions.[color=blue]
>[/color]

All replies - Spot on!

Much appreciated, apology for delay.

Ray.