On Tue, Oct 5, 2021 at 9:50 AM Caleb Donovick <donov...@cs.stanford.edu> wrote: > > > 2) Some OTHER exception occurs on the reevaluation. It's a chained > > exception like any other. > > Except it's not a chained exception and displaying as such would be VERY > confusing IMO. > Granted we could easily strip the chained exception and just return the > original one. So after > reconsideration I agree this is not an issue. > > > It's only really the fourth case that would be confusing > > I generally agree with your analysis but I think this 4th case is more > problematic than you think. > Given no information I am immediately going to split my assertion so I can > see what part is failing. > However, if the interpreter gives me incorrect information I am going to be > super confused. Most people > will not have carefully read section 7.3 of the language reference and will > not understand this critical > aspect of the execution of assertion statements. They will assume that the > interpreter is not lying to them. > > I think storing the intermediate results on the stack is vastly preferable to > revaluation for this reason. >
The trouble is that storing intermediate results is a price paid by every assertion that succeeds, and reevaluating is a price paid only when assertions fail - and the problem you're referring to ONLY happens with broken assertions. Does every assert need to pay the price for the possibility of buggy use of assert? ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4THG6UMO6BNGWDX5L7D6XERI2GRRZHQD/ Code of Conduct: http://python.org/psf/codeofconduct/
