Julython is on!

I'm participating in Julython, are you?


Julython is a great initiative to promote Python developers focusing on their own projects through the month of July and contributing to the community providing great software, great libraries, and great tools. Sign up, track your commits on GitHub and BitBucket, and tell your dev friends to take part.


Julython is going to be a lot of fun!

Here's my profile

How To use Sphinx Autodoc on ReadTheDocs with a Django application

Sphinx is awesome for writing documentation. ReadTheDocs is awesome for hosting it. Autodocs are great for covering your entire API easily. Django is a great framework that makes my job easier.


Between these four things is an interaction that only brought me pain, however. I'm here to help the next dev avoid this.


Autodocs works by importing your modules and walking over the classes and functions to build documentation out of the existing docstrings. It can be used to generate complete API docs quickly and keep them in sync with the libraries existing docstrings, so you won't get conflicts between your docs and your code. Fantastic.

This creates a problem when used with Django applications, where many things cannot be imported unless a valid settings module can be found. This can prevent a hurdle in some situations, and requires a little boilerplate to get working properly with Sphinx. It require a little extra to get working on ReadTheDocs. What makes this particularly hard to figure out, is the environment running on their servers is not the same as your own, and you have only terse error reports to guess about.

Here is the snippet you need to add into the conf.py of your docs/ to tell Sphinx how to load a settings.py.

import sys, os

sys.path.append(os.path.dirname(__file__))
import django 
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings")
if django.VERSION < (1, 4):
    from django.core.management import setup_environ
    settings = __import__(os.environ["DJANGO_SETTINGS_MODULE"])
    setup_environ(settings)


and a simple settings.py is all you need sitting beside that.

# Django settings for docs project.
# import source code dir
import os
import sys
sys.path.insert(0, os.getcwd())
sys.path.insert(0, os.path.join(os.getcwd(), os.pardir))

SITE_ID = 303
DEBUG = True
TEMPLATE_DEBUG = DEBUG

DATABASES = {"default": {
    "NAME": ":memory:",
    "ENGINE": "django.db.backends.sqlite3",
    "USER": '',
    "PASSWORD": '',
    "PORT": '',
}}

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'YOUR_APP_HERE', # This is where you put your app
)


And you should be good to go!

Announcement: Tracerlib 0.1 Released

Tracerlib is a set of utilities to make tracing Python code easier.

It provides TracerManager, which can allow multiple trace functions to coexist. It can easily be enabled and disabled, either manually or as a context manager in a with statement.

Tracer classes make handling the different trace events much easier.

class TraceExceptions(Tracer):
    def trace_exception(self, func_name, exctype, value, tb):
        print "Saw an exception: %r" % (value,) 

Tracer is also easily capable of filtering which events it listens to. It accepts both an  
events parameter, a list of trace events it will respond to, and a watch parameter, a list of paths it will respond to in the form of package.module.class.function.
This can easily wrap a trace function, or you can subclass Tracer and implement one of its helpful trace_*() methods.

And, a helper class FrameInspector which wraps a frame and makes it trivial to inspect the function name and arguments the function had been called with.

inspector = FrameInspector(sys._getframe())

print "Called", inspector.func_name
print "args:", inspector.args
print "kwargs:", inspector.kwargs 

You can read the full documentation at the read the docs site and see the code at github.