Author vstinner
Recipients CyberJacob, Decorater, Matt Groth, ellisj, eric.araujo, lazka, mwh, ncoghlan, pitrou, serhiy.storchaka, tiagoaoa, tim.peters, undercoveridiot, vlasovskikh, vstinner
Date 2019-05-25.23:44:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1558827882.77.0.123976201132.issue1230540@roundup.psfhosted.org>
In-reply-to
Content
> In any case, I think the namedtuple / structseq solution is elegant, because we can add additional information later

I used the same design for the new sys.unraisablehook in bpo-36829 and I'm already working on adding a new 'err_msg' field to the argument passed to this took: PR 13488 :-)

I was trapped in the past when I had to modify warnings "hooks" (warnings.showwarning and warnings.formatwarning) when I had to add a new 'source' parameter. I had to write wrappers which are fragile, to keep the backward compatibility.

> (the user must only be careful not to use tuple unpacking)

threading.excepthook doesn't mention the compatibility with tuple on purpose. It only documents attributes with their names.
History
Date User Action Args
2019-05-25 23:44:42vstinnersetrecipients: + vstinner, mwh, tim.peters, ncoghlan, ellisj, pitrou, tiagoaoa, eric.araujo, undercoveridiot, vlasovskikh, serhiy.storchaka, lazka, Decorater, CyberJacob, Matt Groth
2019-05-25 23:44:42vstinnersetmessageid: <1558827882.77.0.123976201132.issue1230540@roundup.psfhosted.org>
2019-05-25 23:44:42vstinnerlinkissue1230540 messages
2019-05-25 23:44:42vstinnercreate