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

[Twirlip2]

On Tuesday, 26 August 2014 23:03:20 UTC+1, Gregory Ewing  wrote:

> Twirlip2 wrote:
> 
> > There is probably some lesson I should learn from this.
> 
> 
> 
> The lesson is probably that you shouldn't put the code
> 
> you're developing somewhere that's on the default import path.

Most of what I was doing today was splitting up one too-large module into more reasonable-sized and comprehensible pieces - there's still a long way to go! - and arranging for these now-separate modules to import only what they needed from each other.

I had already learned, from section 12.8.5 of Chun's 'Core Python Programming', 2nd ed., how to avoid an interminable cycle of mutual import attempts.

Thus, for example, in one module, I have:

# \Work\Comp\Python\Lib\user.py

"""More functions for interacting with the user in a console session."""

# The importation of these names:
#
#     BeebToken from beeb.py
#     CodeToken from prog.py
#
# has to be postponed for a short while, in order to avoid an interminable
# cycle of attempted importations.

[... some definitions ...]

from beeb import BeebToken
from prog import CodeToken

[etc.]

and then, for example, in one of those two modules (the one that was originally FAR too large, and is still an ugly mess), I have:

# \Work\Comp\Python\Lib\beeb.py

"""Listen to streaming audio."""

# Standard Python 3 library stuff:

from configparser   import ConfigParser
from datetime       import datetime
from functools      import partial
from html.parser    import HTMLParser
from math           import ceil
from os             import getenv, system
from sys            import argv
from urllib.request import urlopen

# My Python 3 library stuff, from <\Work\Comp\Python\Lib\>:

from console3 import get_val
from misc3    import null
from kernel   import Kernel, WebPage
from user     import UserToken, TokenStack

[...]

[By the way, I've read recently - in section 12.5.3 of Chun's book - that all this "from ... import..." stuff that I've been doing is bad style.  That's one of the less urgent things I'll get around to fixing eventually.  At least today I've had a painful lesson in the importance of keeping namespaces clean and tidy!  So I will fix it.  But there are worse things wrong with my code, needing more urgent attention - although the bit I was editing today does work, and the error with the r'\' string was, surprisingly, the only [new] bug in it, apart from an understandable failure to import a few necessary names.]

This works fine - now that the horrible name clash has been resolved! - but it still leaves me open to a recurrence of the same problem, if I get careless.

How do I go about putting my own unstable modules in a safer location, while still being able to import what I want from them?

There's something in Chun's book, which I hadn't read (section 12.7.4), about "relative imports": is that what I should be looking at?

> Although shadowing builtin module names is never a good
> 
> idea, either!

It doesn't seem immediately obvious how to get a definitive list of which names to avoid using (and therefore, inadvertently 'shadowing', as I did today).

For example, <https://docs.python.org/3/tutorial/modules.html#standard-modules> doesn't list the filename 'code.py', which is the one I clashed with today.

Of course, if all else fails, I will be sure to manually search the Python installation directory for possible clashes, but there must be a more logically secure way, one more integral to the language itself.