Multiple "return" statements or "result" variable?

[WolfWayfarer]

I've been wondering about the best option between multiple return statements and the use of an intermediary result variable. This of course in the case of conditional blocks within a function.

I remember that in the little C I took they were passionate about only ever using one single return statement at the end of your function, but in Python I've seen some code with multiple returns.

Is there a convention that states which choice is cleverer in Python? Or some maintenance/readability concern?

For my fellow beginners, here are concrete examples of what I'm talking about (I know this function is too short and not enough detailed to be worth anything, just trying to illustrate my question):

multiple returns

def even_or_not(number):
    """
    boolean type function, returns T if number given in arg is even, F otherwise
    """
    if number % 2 == 0:
        print("Even")
        return True
    else:
        print("Odd")
        return False

use of result variable

def even_or_not(number):
    """
    boolean type function, returns T if number given in arg is even, F otherwise
    """
    if number % 2 == 0:
        print("Even")
        result = True
    else:
        print("Odd")
        result = False
    return result

[ichabod801]

I think having one return is better, as I think it's clearer. However, sometimes when it's an easy way to short circuit further processing, I am weak and I used a mid-function return.

[buran]

check the inks in this @ljmetzger's post (especially the last one from stackexchange). In this last link there is also link to SO question

it looks like the general consensus is this rule (SESE) does not apply to modern languages. the decision one way or the other would take in consideration other factors like readability, etc.

personally I use multiple return statements

[WolfWayfarer]

Allright, I'm not the only one wondering why. After reading that and this part I still have somehow mixed feelings about it.
To think that a field as allegedly "modern" as programming would desperately stick to ancient no-longer-useful ways is surprising.

[snippsat]

In this case can also remove else.

def even_or_not(number):
    if number % 2 == 0:
        return True
    return False

[buran]

In this case can also remove else.

def even_or_not(number): if number % 2 == 0: return True return False

or even

def is_even(number):
    return not number % 2

[WolfWayfarer]

Okay, maybe I shouldn't have put the example since it seems its confusing. I just wanted to illustrate what I was saying, never said this bit of code was correct, I actually stated I knew it was not good. Just wanted to show what I was wondering about. Maybe shouldn't have, bad example.

[perfringo]

If true pythonista is in doubt he/she will turn to holy book of The Python Language Reference for truth, guidance and salvation. As per documentation, every devoted follower keeps it under pillow .

In this case I was not able to find truth. However, guidance is quite clear: every code snippet that I have encountered so far is using multiple returns. Like in Built-in functions all(), any() or Built-in Types hashing float etc.

The smart people who wrote these snippets were well aware that millions on eager young pythonistas will consider these examples as best practices for Python code.

Conclusion is simple: using multiple returns is pythonic

One can be tempted to derive from that: using multiple results and one return is non-pythonic. I am not commited to that yet. In order to claim that I need to read all snippets provided and only after that make conclusion.