def get_iterstuff(source: Thingy, descr: Optional[str]) -> Iterable[Stuff]: """ Return an iterator of Stuff instances from a given Thingy """ key = prepare_descr(descr) # may be a “str”, may be None val = getattr(source, key, None) # val has type Optional[Iterable[Stuff]] if not val: # None, or (in some cases) an empty return IterStuff.EMPTY # sentinel, with the same type as val return val # the likeliest codepath
… where one
if statement can return early – in some such functions, earlier than any of the preparatory function calls, like those in the first two lines of this example here.
This works fine. I mean, I believe there are some peephole-optimization-related complications that arise in functions with multiple
return statements†. But generally though, like so many other Pythoneers I do this kind of thing literally all the time, to produce testable, maintainable, and legibly flow-controlled functions that can be run without incurring any great big-O wrath.
But so, my question is regarding the manner in which this logic takes a slightly different form, e.g. when the function is a generator that makes use of one or more
yield from statements:
def iterstuff(source: Thingy, descr: Optional[str]) -> YieldFrom[Stuff]: # ‡ key = prepare_descr(descr) # may be a “str”, may be None val = getattr(source, key, None) # val has type Optional[Iterable[Stuff]] if not val: yield from tuple() # … or suchlike else: yield from val # the likeliest codepath
- The second
yield fromstatement, which forms the end of the functions’ likeliest codepath, is within an
elseclause and not at the top level of the functions’ code block.
- There is this odd use of the
yield fromsomething empty and iterable.
… Now, so, I do know that the use of the
else is necessitated by the fact that control falls through
yield from statements after they’ve been exhausted (which is a quality that, in other cases, I love to use and abuse). And sticking the
tuple(…) thing in there is way easier than, like, all the legwork that’d have to go into concocting the kind of sentinel that
IterStuff.EMPTY, from the first function, would be.
yield from example does look jankier than its
return-based counterpart. More fragile. Less considered. Code-smelly, if you will.
So I ask: what’s the most legible, least consequential, and optimally most Pythonic way to structure the
yield from version of this?
tuple() code-wart OK, or are there less programmatically odiferous alternatives?
‡ – the “YieldFrom” generic type alias simplifies annotating these generator functions – as
typing.Generator is a bit over-the-top, as written. It looks like this:
class YieldFrom(Generator[T_co, None, None]): """ Simple “typing.Generator” alias. The generic Generator from “typing” requires three type params: • “yield_type” (covariant), • “send_type” (contravariant), and • “return_type” (covariant). … a function containing 1..n “yield” or “yield from” statements – without returning anything and unburdened by any expectations of calls to its “send(…)” method showing up in any type-festooned code – can make use of this “YieldFrom[T]” alias. ÷Explict beats implict÷ """ pass