In a function call, `f(x for x in iterable)` is roughly equivalent to `f(iter(iterable))`, not `f(*iterable)` (the genexp based equivalent of the latter would be ``f(*(x for x in iterable))`). Thus the base class list is no different from any other argument list in this case - it's just that generator objects aren't valid base classes. Getting back on topic for this particular bug fix though: as noted in my last PR review, I think the latest version goes too far by disallowing `@deco(x for x in iterable)` and `class C(x for x in iterable):`. While semantically questionable, there's nothing *syntactically* invalid about those - they pass a single generator expression, and that generator expression is correctly surrounded by parentheses. There's no more reason to prohibit a genexp in either of those situations at compile time than there is to prohibit a list comprehension.