On Nov 1, 2015 14:45, "Erik" <python@lucidity.plus.com> wrote:
>
> On 01/11/15 09:49, Laura Creighton wrote:
>>
>> Adding warnings to IDLE when you save a file is a fine idea, and will
>> help IDLE users avoid pain.  I want to help _everybody_ with a change
>> to Python, so that it issues a warning when you shadow something in
>> the standard library.
>
>
> I think that a solution to this could be something along the lines of having a command line switch (let's say '-w') or other way of enabling a "shadow module checking" mechanism.
>
> When an exception is thrown that is caught by the default handler and output to stderr, an additional line of output could be appended:
>
> "Note: This problem could be caused by a module that shadows a standard library or third party module. Run Python with the '-w' switch for more detail."
>
> I'm not sure if this would be suitable for _all_ exceptions or only those from certain points in the exception hierarchy.
>
> When the '-w' switch is enabled, the default exception handler would instead enumerate all active modules and, for any which has another module with the same name further down the search path than the one that is loaded, would output some sort of diagnostic message (i.e., a list of which loaded modules are shadowing _something_else_ that would have been loaded otherwise) - similar to your example below:
>
>
>> Something like:
>> Warning: local file /u/lac/junk/string.py shadows module named string in the
>> Standard Library
>
>
> This would prevent "power users" from always having to see a potentially large diagnostic after each uncaught exception, but generally remind everyone that such a thing is possible and "here's the easy way to check for it".
>
> A bit like Valgrind's memcheck tool's "--leak-check=full" option - when run without it, if there are leaks then memcheck reminds the user that that's the way to start digging down into what might be causing them.

I was thinking of something like this too.  A list of stdlib modules could be created statically when python is originally built (if it isn't already).  This would have no changes in behaviour unless an error actually happens.  And maybe to avoid any performance cost the message can only be inserted when the interpreter actually exits, if that makes any sense at all.