IDLE has suddenly become FAWLTY - so should I be hitting it with a big stick, or what?

[Chris Angelico]

On Wed, Aug 27, 2014 at 10:01 AM, Steven D'Aprano
<steve+comp.lang.python at pearwood.info> wrote:
> Gregory Ewing wrote:
>
>> Although shadowing builtin module names is never a good
>> idea, either!
>
> /s/builtin/standard library/
>
> Quick! Name all the standard library modules, stat!
>
> In Python 3.3, there are something like 410 modules in the standard library.
> There's a reasonable chance that you've shadowed at least one but never
> noticed. Yet.

Not sure about that figure; any that are namespaced away in packages
don't count (or rather, they count as just one, for the package
itself). But yes, there are a lot.

> I think it is a serious design flaw that the standard library and user code
> co-exist in a single namespace.

There are two concerns here. One is that if you create a "random.py",
you can't yourself import the normal random module; and the other is
the possibility that some unrelated application like Idle can be
affected. I think the latter is far more serious than the former,
which is basically equivalent to using "id" as a variable name and
then finding you've shadowed a builtin (it affects only your current
module, so it's pretty safe). But if I can create stuff that breaks
Idle, that's a problem. And I think the solution to that is simply:
never put your files onto the module search path, always just use the
current directory. It might also be worth having some tools like Idle
remove "" from sys.path, in case someone invokes it from a project
directory, but that's an arguable point. (That's probably more useful
for something like 2to3, where it's expected that you'll run it from a
project directory. And maybe that already happens.)

The only other way to separate them would be to do something like C's
include paths - you have the user include path (which starts with the
current directory) and the system include path (which doesn't), and
then you can #include "local_file.h" and #include <system_file.h> to
get the one you want. In Python, that could be done as "import random
from system", which would then look up sys.systempath instead of
sys.path - but do we really need that functionality?

ChrisA