Message343524
> 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. |
|
Date |
User |
Action |
Args |
2019-05-25 23:44:42 | vstinner | set | recipients:
+ vstinner, mwh, tim.peters, ncoghlan, ellisj, pitrou, tiagoaoa, eric.araujo, undercoveridiot, vlasovskikh, serhiy.storchaka, lazka, Decorater, CyberJacob, Matt Groth |
2019-05-25 23:44:42 | vstinner | set | messageid: <1558827882.77.0.123976201132.issue1230540@roundup.psfhosted.org> |
2019-05-25 23:44:42 | vstinner | link | issue1230540 messages |
2019-05-25 23:44:42 | vstinner | create | |
|