Message343524
| 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: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 | |