A C-like if statement

[Bob Greschke]

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

Thanks!

Bob

[Roy Smith]

Bob Greschke <bo*@passcal.nmt.edu> wrote:

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

It is a deliberate and fundamental design decision in Python that
assignment is a statement, not an expression with side effects. This
means you often need an "extra" line compared to a classic C "assign
and test" idiom such as you have above. I, like you, often miss the
compactness of the C idiom, but there it is.

It's also unpythonic to return magic values to indicate failure.
Throwing an exception would be the more normal way of doing it. So,
I'd expect the above to translate into something like:

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"

[Bob Greschke]

"Roy Smith" <ro*@panix.com> wrote in message
news:dt**********@reader2.panix.com...

Bob Greschke <bo*@passcal.nmt.edu> wrote:

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement
gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

It is a deliberate and fundamental design decision in Python that
assignment is a statement, not an expression with side effects. This
means you often need an "extra" line compared to a classic C "assign
and test" idiom such as you have above. I, like you, often miss the
compactness of the C idiom, but there it is.

It's also unpythonic to return magic values to indicate failure.
Throwing an exception would be the more normal way of doing it. So,
I'd expect the above to translate into something like:

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"

Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)

I think your way would work if .find() were replaced with .index(). I'm
just trying to clean up an if/elif tree a bit, so using try would make
things bigger.

Thanks!

Bob

[Giles Brown]

But maybe we're talking about string methods so to get an exception
we'd want to use "index" instead of "find".

Giles

[Dave Hansen]

On Thu, 23 Feb 2006 12:04:38 -0700 in comp.lang.python, "Bob Greschke"
<bo*@passcal.nmt.edu> wrote:

"Roy Smith" <ro*@panix.com> wrote in message
news:dt**********@reader2.panix.com...

[...]

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"

Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)

I think you'll find that BASIC doesn't allow it either...

Of the "missing" "features" of Python, this one is waaaaaay down on my
list. In fact, it's not there at all. What I _really_ miss is
do{...}while. The best workaround I've found is unaesthetic, IMHO:

while 1:
# stuff
if exit_condition: break

Regards,
-=Dave

--
Change is inevitable, progress is not.

[Steven D'Aprano]

On Thu, 23 Feb 2006 12:04:38 -0700, Bob Greschke wrote:

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"
Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)

There are *reasons* why Python discourages functions with side-effects.
Side-effects make your code hard to test and harder to debug.
I think your way would work if .find() were replaced with .index(). I'm
just trying to clean up an if/elif tree a bit, so using try would make
things bigger.

Then write a function! Instead of calling the try..except block in every
branch directly, pull it out into a function:

def test(s,what):
try:
i = s.index(what)
print "It's here: ", i
except ValueError:
print "No 3's here"
--
Steven.

[bonono]

Steven D'Aprano wrote:

On Thu, 23 Feb 2006 12:04:38 -0700, Bob Greschke wrote:

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"

Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)

There are *reasons* why Python discourages functions with side-effects.
Side-effects make your code hard to test and harder to debug.

"test".index("a") Traceback (most recent call last):
File "<pyshell#0>", line 1, in -toplevel-
"test".index("a")
ValueError: substring not found "test".find("a")

-1

[Paul Rubin]

"Bob Greschke" <bo*@passcal.nmt.edu> writes:

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

For regexps I sometimes do it with a specially created class instance.
Something like:

save = Cache_match()

if save.find(a, "3"):
print "it's here:", save.result
else:
print "no 3's here"

Implementing Cache_match is left to you as an exercise. It does make
your code a bit cleaner if you're doing lots of matching.

[Terry Hancock]

On Fri, 24 Feb 2006 09:14:53 +1100
"Steven D'Aprano" <st***@REMOVETHIScyber.com.au> wrote:

There are *reasons* why Python discourages functions with
side-effects. Side-effects make your code hard to test and
harder to debug.

You of course meant "expressions with side-effects". Python
is pretty good at making functions with side-effects. At
least it is if you want them. ;-)

--
Terry Hancock (ha*****@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com

[Steven D'Aprano]

On Thu, 23 Feb 2006 20:41:52 -0600, Terry Hancock wrote:

On Fri, 24 Feb 2006 09:14:53 +1100
"Steven D'Aprano" <st***@REMOVETHIScyber.com.au> wrote:

There are *reasons* why Python discourages functions with
side-effects. Side-effects make your code hard to test and
harder to debug.

You of course meant "expressions with side-effects". Python
is pretty good at making functions with side-effects. At
least it is if you want them. ;-)

Yes, of course I meant that.

However, functions with side-effects are also discouraged. Unless
side-effects are the correct way to do whatever it is you are trying to
do, in which case they are encouraged.

*wink*
--
Steven.

[Steven D'Aprano]

On Thu, 23 Feb 2006 16:49:09 -0800, bonono wrote:

Steven D'Aprano wrote:

On Thu, 23 Feb 2006 12:04:38 -0700, Bob Greschke wrote:

>> try:
>> i = a.find("3")
>> print "It's here: ", i
>> except NotFound:
>> print "No 3's here"
>
> Nuts. I guess you're right. It wouldn't be proper. Things are added or
> proposed every day for Python that I can't even pronounce, but a simple 'if
> (I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
> to BASIC. :)

There are *reasons* why Python discourages functions with side-effects.
Side-effects make your code hard to test and harder to debug.

"test".index("a") Traceback (most recent call last):
File "<pyshell#0>", line 1, in -toplevel-
"test".index("a")
ValueError: substring not found "test".find("a")

-1

Did you have a point?

In case you haven't been following the entire thread, the original bit of
code above (the try block using the find method) wasn't mine. It just
happened to be quoted in my post.
Now that's a Python wart: using >>> for the prompt for interactive
sessions. It makes it ambiguous when posting code in email or newsgroups,
especially once the code gets quoted a few times.
--
Steven.

[bonono]

Steven D'Aprano wrote:

On Thu, 23 Feb 2006 16:49:09 -0800, bonono wrote:

Steven D'Aprano wrote:

On Thu, 23 Feb 2006 12:04:38 -0700, Bob Greschke wrote:

>> try:
>> i = a.find("3")
>> print "It's here: ", i
>> except NotFound:
>> print "No 3's here"
>
> Nuts. I guess you're right. It wouldn't be proper. Things are added or
> proposed every day for Python that I can't even pronounce, but a simple 'if
> (I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
> to BASIC. :)

There are *reasons* why Python discourages functions with side-effects.
Side-effects make your code hard to test and harder to debug.

> "test".index("a")

Traceback (most recent call last):
File "<pyshell#0>", line 1, in -toplevel-
"test".index("a")
ValueError: substring not found

> "test".find("a")

-1

Did you have a point?

It was about your side-effect talk, if you failed to see it, that is
fine.

BTW, it seems that the term side-effect of function used is a bit
different from my understanding of how it is in general used in this
field.

[Steven D'Aprano]

On Fri, 24 Feb 2006 02:02:02 -0800, bonono wrote:

>>>> "test".index("a")
> Traceback (most recent call last):
> File "<pyshell#0>", line 1, in -toplevel-
> "test".index("a")
> ValueError: substring not found
>>>> "test".find("a")
> -1

Did you have a point?

It was about your side-effect talk, if you failed to see it, that is
fine.

BTW, it seems that the term side-effect of function used is a bit
different from my understanding of how it is in general used in this
field.

What side effect?

Returning magic values (e.g. -1 to indicate "not found") is not a
side-effect in any terminology I've come across.

A side-effect would be if s.index(substr) not only returned the index as
promised, but also (say) appended substr to a list somewhere.

Side-effects aren't always bad (import, for example, does all its work by
side-effect). But they are generally frowned upon, and in functional
languages they are verboten.
--
Steven.

[Kent Johnson]

Steven D'Aprano wrote:

Now that's a Python wart: using >>> for the prompt for interactive
sessions. It makes it ambiguous when posting code in email or newsgroups,
especially once the code gets quoted a few times.

So change it. My pythonstartup.py contains:

import sys
sys.ps1 = ' >>> '
sys.ps2 = ' ... '

Kent

[Antoon Pardon]

Op 2006-02-23, Roy Smith schreef <ro*@panix.com>:

Bob Greschke <bo*@passcal.nmt.edu> wrote:

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

It is a deliberate and fundamental design decision in Python that
assignment is a statement, not an expression with side effects.

The only motivation I have heard for this decision is to easily
find typo related bugs. I can hardly find that a fundamental
design decision.

--
Antoon Pardon

[Steven D'Aprano]

On Fri, 24 Feb 2006 06:45:41 -0500, Kent Johnson wrote:

Steven D'Aprano wrote:

Now that's a Python wart: using >>> for the prompt for interactive
sessions. It makes it ambiguous when posting code in email or newsgroups,
especially once the code gets quoted a few times.

So change it. My pythonstartup.py contains:

import sys
sys.ps1 = ' >>> '
sys.ps2 = ' ... '

Sure, I can change my prompt. And you can change yours. And Bob can change
his. And Freddy doesn't bother. And now we've all got different prompts,
and nobody knows what's what...

It is good to be able to set your own prompt when needed. But it is also
good to have a common default prompt. And it would be good for that common
default prompt to NOT clash with email quoting standards. Therefore that
the prompt actually does clash is a wart.

That's my opinion. Yours may differ.

--
Steven.

[Roy Smith]

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

Side-effects aren't always bad (import, for example, does all its work by
side-effect). But they are generally frowned upon, and in functional
languages they are verboten.

How do you do any I/O in a functional language if side effects are
verboten? For that matter, how does a functional program ever stop running?

[Rene Pijlman]

Roy Smith:

How do you do any I/O in a functional language if side effects are
verboten?
The user is a function. Output is its parameter, input its return value.
The user is not allowed to maintain state ;-)
For that matter, how does a functional program ever stop running?

By returning to the caller.

--
René Pijlman

[Steven D'Aprano]

On Fri, 24 Feb 2006 08:03:49 -0500, Roy Smith wrote:

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

Side-effects aren't always bad (import, for example, does all its work by
side-effect). But they are generally frowned upon, and in functional
languages they are verboten.

How do you do any I/O in a functional language if side effects are
verboten? For that matter, how does a functional program ever stop running?

Fair enough.

But still, ignoring unavoidable cases like writing to a file, the ideal of
functional languages is for side-effects to not exist.

--
Steven.

[Diez B. Roggisch]

Roy Smith wrote:

In article <pa****************************@REMOVETHIScyber.co m.au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

Side-effects aren't always bad (import, for example, does all its work by
side-effect). But they are generally frowned upon, and in functional
languages they are verboten.

How do you do any I/O in a functional language if side effects are
verboten? For that matter, how does a functional program ever stop
running?

Using Monads. Which basically starts carrying around explicit state in an
implicit manner. But that is restricted to very few, specific portions of
the program.

Diez

[Kay Schluehr]

Roy Smith wrote:

Bob Greschke <bo*@passcal.nmt.edu> wrote:

I miss being able to do something like this in Python

1f (I = a.find("3")) != -1:
print "It's here: ", I
else:
print "No 3's here"

where I gets assigned the index returned by find() AND the if statement gets
to do its job in the same line. Then you don't have to have another like
that specifically gets the index of the "3". Is there a way to do this in
Python?

It is a deliberate and fundamental design decision in Python that
assignment is a statement, not an expression with side effects. This
means you often need an "extra" line compared to a classic C "assign
and test" idiom such as you have above. I, like you, often miss the
compactness of the C idiom, but there it is.

Hmm. A statement has side-effects but it returns no value. And yes, you
can create a name within an expression producing a value in Python,
using a list/generator comprehension. The solution to Bob's problem
would look like this:

if (I for I in (a.find("3"),) ) != -1:
print "It's here: ", I
else:
print "No 3's here"
Kay

[Paul Rubin]

"Kay Schluehr" <ka**********@gmx.net> writes:

Hmm. A statement has side-effects but it returns no value. And yes, you
can create a name within an expression producing a value in Python,
using a list/generator comprehension. The solution to Bob's problem
would look like this:

if (I for I in (a.find("3"),) ) != -1:
print "It's here: ", I
else:
print "No 3's here"

I think that works for list comprehensions but not generator
comprehensions. With generator comprehensions, the index variable's
scope is limited to the comprehension. With list comprehensions
there's a wart in that the index variable is still around afterwards.

[Kay Schluehr]

Paul Rubin wrote:

"Kay Schluehr" <ka**********@gmx.net> writes:

Hmm. A statement has side-effects but it returns no value. And yes, you
can create a name within an expression producing a value in Python,
using a list/generator comprehension. The solution to Bob's problem
would look like this:

if (I for I in (a.find("3"),) ) != -1:
print "It's here: ", I
else:
print "No 3's here"
I think that works for list comprehensions but not generator
comprehensions. With generator comprehensions, the index variable's
scope is limited to the comprehension.

Right. It becomes even more ugly yet:

if [I for I in ("1,2,3".find("3"),) ] != [-1]:
print "It's here: ", I
else:
print "No 3's here"
With list comprehensions
there's a wart in that the index variable is still around afterwards.

Definitely, but index variable survival is nothing that entered Python
with list-comps:

for k in range(2):
print k

k

1

Kay

[Cameron Laird]

In article <pa***************************@REMOVETHIScyber.com .au>,
Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Thu, 23 Feb 2006 12:04:38 -0700, Bob Greschke wrote:

try:
i = a.find("3")
print "It's here: ", i
except NotFound:
print "No 3's here"

Nuts. I guess you're right. It wouldn't be proper. Things are added or
proposed every day for Python that I can't even pronounce, but a simple 'if
(I = a.find("3")) != -1' isn't allowed. Huh. It might be time to go back
to BASIC. :)

There are *reasons* why Python discourages functions with side-effects.
Side-effects make your code hard to test and harder to debug.

I think your way would work if .find() were replaced with .index(). I'm
just trying to clean up an if/elif tree a bit, so using try would make
things bigger.

Then write a function! Instead of calling the try..except block in every
branch directly, pull it out into a function:

def test(s,what):
try:
i = s.index(what)
print "It's here: ", i
except ValueError:
print "No 3's here"