This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pablogsal
Recipients Mark.Williams, aldwinaldwin, miss-islington, ned.deily, nedbat, p-ganssle, pablogsal, scoder, serhiy.storchaka, tim.peters, xtreak
Date 2019-07-05.21:45:50
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1562363151.22.0.902959338201.issue37500@roundup.psfhosted.org>
In-reply-to
Content
> CPython has acted the current way for about 15 years (since 2.4 was released), and this is the first time anyone has raised an objection.

Although I tend to agree with your words, I have to insist that correctness in the reference implementation is very important, is not just a "pragmatic" thing. For example, under this argument, we could say that it does not matter if

def f():
  if 0:
    yield

should be or not a generator. But that changes things massively. It happens that it will always be a generator due to how we check for that property, but under this argument is ok if it is undefined.

This also makes the thing even more confusing as there are some syntax consequences of unreachable code, but no others. (Like the bytecode for that yield will be gone!!. Is impossible to know if that is a generator or not from the bytecode).

I have seen many people confused already and it makes very difficult to guess what are the consequences of code that is unreachable at runtime. For these reasons I think consistency is key.

I agree that the way this is done is not ideal, but we could not find a better way to do this :(
History
Date User Action Args
2019-07-05 21:45:51pablogsalsetrecipients: + pablogsal, tim.peters, scoder, nedbat, ned.deily, serhiy.storchaka, Mark.Williams, p-ganssle, miss-islington, xtreak, aldwinaldwin
2019-07-05 21:45:51pablogsalsetmessageid: <1562363151.22.0.902959338201.issue37500@roundup.psfhosted.org>
2019-07-05 21:45:51pablogsallinkissue37500 messages
2019-07-05 21:45:50pablogsalcreate