Back in my VB6 days, I created a custom error handling framework to provide something like try/catch semantics. Part of the toolkit was an IDE extension which added (or stripped) line numbers and boilerplate entry/exit code to functions.
It was game-changing to be able to immediately pinpoint most issues right down to the line number (especially along with the stack trace I generated). Could never understand why we didn't have more languages that let you do that.
And before HN chastizes me... I did try several other third party error handling frameworks first (some very expensive) - they were all buggy and crap, that's why I rolled my own. Even brought that tech along to some clients I consulted for a decade later and it helped devs speed up debugging their enterprise software.
I find that for PEPs like this there is not adequate discussion of performance implications. It describes an "opt-out" mechanism which suggests that Python programs will and should by default incur a performance penalty for this behavior. Broadly it's indicative of a culture that wants all the features without putting thought to how slow the language implementation is.
> As an illustrative example to gauge the impact of this change, we have calculated that this change will increase the size of the standard library’s pyc files by 22% (6MB) from 28.4MB to 34.7MB. The overhead in memory usage will be the same (assuming the full standard library is loaded into the same program)...
The authors then go on to discuss that they tested it against several of the larger popular libraries. I think they gave some serious thought to the performance ramifications, but that they didn't see one.
They go into detail about why they're only storing an extra uint8_t, and the compromises that makes, but that the fact that it doesn't impact performance is what makes those compromises worthwhile.
I don't think this PEP falls into a culture indicative of not being thoughtful around the tradeoffs involved in language design.
It was game-changing to be able to immediately pinpoint most issues right down to the line number (especially along with the stack trace I generated). Could never understand why we didn't have more languages that let you do that.
And before HN chastizes me... I did try several other third party error handling frameworks first (some very expensive) - they were all buggy and crap, that's why I rolled my own. Even brought that tech along to some clients I consulted for a decade later and it helped devs speed up debugging their enterprise software.