If/then style question

[Carl Banks]

If your function has so many exit points that you can miss some of them
while editing, your function is too big, does too much, or both.

Sanctimonious much? In the real world, people "miss things" and "make
mistakes" and not necessarily because they are working on something
too complex to handle. It happens.


Carl Banks

 

[Steven D'Aprano]

Sanctimonious much? In the real world, people "miss things" and "make
mistakes" and not necessarily because they are working on something too
complex to handle. It happens.

Really? I had no idea. I've never made a misteak, I asumed evrybody else
was equally brilliant. No, wait, there was that one time...

*wink*

Of course people make mistakes. So what's your point?

The point I was trying to make is that rather than encouraging an idiom
(only one return statement, even if the algorithm is more clearly written
with multiple exists) that leads to more complex, less efficient code
just in case you might someday need to modify the return result, there
are simple alternatives that avoid the need for anti-patterns like copy-
and-paste coding or enforced single exit point. I gave two:

- refactor the complex code so that it's less complex (e.g. instead of 20
exit points, which makes it easy to miss one or two, refactor it so there
are two or three exit points); or if that's not practical:

- wrap it in a decorator that performs the post-processing you need.

Both can be simple, effective and Pythonic. Neither require the coder to
use an artificial idiom just in case of some future need. The decorator
solution works even if you don't have access to the source code, or if
the function is a complex black box that nobody understands well enough
to touch.

 

[Francesco]

I'd bet you would stress your point Steven! But you don't need to persuade me, I do already agree.
I just meant to say that, when the advantage is little, there's no need to rewrite a working function.
And that with modern CPUs, if tests take so little time, that even some redundant one is not so much of a nuisance.
in your working example, the "payload" is just a couple of integer calculations, that take very little time too. So the overhead due
to redundant if tests does show clearly. And also in that not-really-real situation, 60% overhead just meant less than 3 seconds.
Just for the sake of discussion, I tried to give both functions some plough to pull, and a worst-case situation too:
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1
53.011015366479114-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1
-1 -1 -1 -1 -1 -1 -1 -1
47.55442856564332

that accounts for a scant 11% overhead, on more than one million tests per cycle.

That said, let's make really clear that I would heartily prefer func2 to func1, based both on readability and speed. Thank you for
having spent some time playing with me!
Francesco