On Jan 30, 2016 6:45 PM, "Andrew Barnert via Python-ideas" <python-ideas@python.org> wrote:
>
> On Jan 29, 2016, at 22:58, Sjoerd Job Postmus <sjoerdjob@sjec.nl> wrote:
> >
> >> On Fri, Jan 29, 2016 at 04:16:46PM -0800, Andrew Barnert wrote:
> >>> On Jan 29, 2016, at 15:42, Sjoerd Job Postmus <sjoerdjob@sjec.nl> wrote:
> >>>
> >>> Maybe a suggestion would be to add the path of the module to the error
> >>> message?
> >>
> >> That would probably help, but think about what it entails:
> >>
> >> Most AttributeErrors aren't on module objects, they're on instances of user-defined classes with a typo, or on None because the user forgot a "return" somewhere, or on str because the user didn't realize the difference between the string representation of an object and the objects, etc.
> >
> > True. Most AttributeErrors are on user-defined classes with a typo. But
> > that's not the case we're discussing here. Here we are discussing how a
> > user should debug the effects of module name collisions, and the
> > resulting AttributeError.
>
> Right. So my point is, either we have to do the extra work in module.__getattr__ when formatting the string, or we have to extend the interface of AttributeError to carry more information in general (the object and attr name, presumably). The latter may be better, but it's also clearly not going to happen any time soon. (People have been suggesting since before 3.0 that all the standard exceptions should have more useful info, but nobody's volunteered to change the hundreds of lines of C code, Python code, and docs to do it...)

Pep 473 centralizes all of this requests. https://www.python.org/dev/peps/pep-0473/.

I started adding support for name error, the most simple change and it turned out to be much more complex as I had thought. I had a couple of tests which were failing and didn't have the bandwidth to debug.
>
> So, the only argument against your idea I can see is the potential performance issues. Which should be pretty easy to dismiss with a microbenchmark showing it's pretty small even in the worst case and a macrobenchmark showing it's not even measurable in real code, right?
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/