Question

I’m building a web application with Twisted, and for the site resources I have a structure like this:

/resources
    __init__.py
    file.py
    javascript.py
    images.py
    wsdl.py
/pages
    __init__.py
    page.py
    static.py
    login.py
    ...etc...

where file.py and page.py contain parent classes with common functionality (filepath validation and sessions/templates, respectively, for example). Each other script contains a single class which is a single twisted resource. my __init__.py files look like this:

import javascript
Javascript = javascript.Javascript

import images
Images = images.Images

...

so that, in the main script, before handing execution over to twisted, I can just import resources; import pages and then just reference resources.Javascript(), pages.Login(), etc, instead of having to write

from resources.javascript import Javascript
from resources.images import Images
from resources.wsdl import WSDL
from pages.static import Static
from pages.login import Login
...

and then use each of those classes to build the site structure. It gets unruly pretty quickly.

Note that I’m not approaching this with an “I am an always will be the sole developer on this project so it doesn’t matter” mentality.

So is this an inhumane abuse of the import system? Should I just buckle and use from pages import * and then use pages.Static(), pages.Login(), etc?

If this is appropriate for the site resources since each file contains a single class acting as that resource, would it be inappropriate to adopt elsewhere to avoid long strings of imports, or would it just lead to headaches?

Answer 1

Is there any reason you do not want to use (in resources/__init__.py):

from javascript import Javascript
from images import Images

This would mean that in client code you can still do:

import resources
js = resources.Javascript()
imgs = resources.Images()

In either case, I do not think there is anything wrong in importing various definitions in __init__.py to make them available directly through importing of the library/subpackage namespace. It is a common enough idiom, and I use it often.