asyncio: What is the difference between tasks, futures, and coroutines?

[Chris Angelico]

On Fri, May 8, 2015 at 9:53 PM, Dave Angel <davea at davea.name> wrote:
> One thing newbies get tripped up by is having some path through their code
> that doesn't explicitly return.  And in Python that path therefore returns
> None.  It's most commonly confusing when there are nested ifs, and one of
> the "inner ifs" doesn't have an else clause.
>
> Anyway, it's marginally more useful to that newbie if the compiler would
> produce an error instead of later seeing a runtime error due to an
> unexpected None result.
>
> I don't think Python would be improved by detecting such a condition and
> reporting on it.  That's a job for a linter, or a style guide program.

They're not hard for linters to notice. After all, there's a clear
difference of intent between "return" (or just falling off the end of
the function) and "return None", even though they compile to the same
byte code. Though if you start enforcing that in your checkin policy,
you might have to deal with this kind of thing:

def raise_with_code(code):
    raise SpamError("Error %d in spamination: %s" % (code,
errortext.get(code, "<unknown>")))

def spaminate_text(f):
    rc = low_level_spamination_function(f)
    if not rc: return low_level_get_spamination_result()
    raise_with_code(rc)

Clearly one branch returns a value... but figuring out that the other
one always raises isn't easy. (Though I suppose in this case it could
be dealt with by having a function that constructs the error, and then
you "raise make_spam_error(rc)" instead.)

You're definitely right that Python shouldn't check for it.

ChrisA