# Maybe a Recipe for itertools

from collections.abc import Iterable

def flatten_all(iterable):
    # -> 'one'
    # <- ['one']
    # -> ['one', [b'two', b'three'], ['four', ('five', (1, {'e', 'ee'}, (2, (3, ))), ['six'])], generator()]
    # <- ['one', b'two', b'three', 'four', 'five', 1, 'ee', 'e', 2, 3, 'six', 0, 1, 2]

    if isinstance(iterable, Iterable) and not isinstance(iterable, (str, bytes)):
        for it in iterable:
            yield from flatten_all(it)
    else:  # int & others types as is.
        yield iterable


if __name__ == "__main__":

    # Test Only
    def generator():
        for i in range(3):
            yield i

    a = ['one', [b'two', b'three'], ['four', ('five', (1, {'e', 'ee'}, (2, (3, ))), ['six'])], generator()]
    # a = 'one'
    # a = (True, False)

    print(list(flatten_all(a)))

In proposed implementation str and bytes are not flattened. What about bytearray? array.array? memoryview? For different tasks they can be considered atomic or as collections. There are such much task specific details and the implementation is such simple, that I think there is no need add this function in itertools. And due to this details it may be not worth to add it as a recipe.

Currently there is flatten() function in itertools Recipes section. This is what it does:
-> a = ['one', 'plus', [b'two', b'three'], ['four', ('five', (1, {'e', 'ee'}, (2, (3, ))), ['six'])], generator()]
<- ['o', 'n', 'e', 'p', 'l', 'u', 's', b'two', b'three', 'four', ('five', (1, {'ee', 'e'}, (2, (3,))), ['six']), 0, 1, 2]

As you can see it only flattens 1 nested level and for some reason it explodes the 'one' and 'plus' str items (maybe intentionally designed or lazily ignored, i don't know).

This is useful maybe in special circumstances where you have:
-> a = [[1, 2, 3], ['one', 'two', 'three']]
<- [1, 2, 3, 'one', 'two', 'three']

Also it doesn't work with bytearray, memoryview ...


In real worldly use something like flatten_all() is more useful!

> I think there is no need add this function in itertools. 
> And due to this details it may be not worth to add it as a recipe.

Sorry YoSTEALTH, I concur with Serhiy on both points and am going to pass on this proposal. 

That said, I encourage you to post elsewhere.  When my own ideas don't make it to the docs or standard library, I usually post a recipe in the ASPN Python Cookbook (for example, see https://code.activestate.com/recipes/users/178123/ ).