Author ncoghlan
Recipients benjamin.peterson, brett.cannon, cryvate, ncoghlan, serhiy.storchaka, yselivanov
Date 2017-11-14.00:26:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1510619190.09.0.213398074469.issue32012@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017-11-14 00:26:30ncoghlansetrecipients: + ncoghlan, brett.cannon, benjamin.peterson, serhiy.storchaka, yselivanov, cryvate
2017-11-14 00:26:30ncoghlansetmessageid: <1510619190.09.0.213398074469.issue32012@psf.upfronthosting.co.za>
2017-11-14 00:26:30ncoghlanlinkissue32012 messages
2017-11-14 00:26:30ncoghlancreate