Refactor how imports work

[JayFoxRox]

Example:

from . import *
from . import memory
from .apu_regs import *
from .aci import export_wav

I'm not a python coder, but I assume this is quite horrible..

[IsFlwrs]

Hi @JayFoxRox

Can you explain me what libraries do you want to import?
As a recommendation, is important only import just the elements that you will need.

Some examples:
from models import model1, model2, model3

In the follow link you can find more information:
https://docs.python.org/2/tutorial/modules.html

[JayFoxRox]

This is not so much about imports from other dependencies. It's about importing our own code, basically inter-module dependencies.

I don't really know myself what is there to fix to be honest. I just wish some python coder would look over this, and do a massive refactor to set up a good skeleton for further work.

Again: I'm not a python coder, so it's really hard to explain what exactly is wrong; however, I have heard (and also see myself) that it is quite horrible.

---

It used to be that xboxpy was more like a bash-script: you included xbox.py (now called xboxpy.py) and it automatically connected to the Xbox, and the def'd all functions in the global namespace by importing other python files.

That was done for lazyness as I didn't want to explicitly import each module I needed during initial development of helper scripts.
It was also done because importing a single module from gdbs python extension should make a fully functional Xbox debugger within gdb (where you don't have to import more).

However, some ugly things about this:

• It's non-standard python
• It clutters up the default "namespace" (what I mean is, it does def read():)
• It re-defines function during initial loading / bootstrapping; for example, there is one version of "read()" to call another import (which uses read()) to retrieve kernel information. That information is then used to create a better version of "read()" which replaces the previous one.
• It might have unintended side-effects (I heard that importing from . and import * are evil things that import opened gates to hell)
• xboxpy has grown enough that we might want multiple Xbox connections at the same time (this also affects other issues; also see Refactor interface selection #5 ), so we should use object orientation
• xboxpy provides so many functions, that we need a clean design and structure now (nv2a.py should probably be multiple modules itself soon?)

---

These lines from xboxpy.py (originally just th gdb loader) probably also needs some review:

# Add ourselves to the module path first
if not "" in sys.path:
sys.path += [""]

(which is probably fine for the gdb loader, but not for anything else?)