So, a few summaries of things I'm ready to decide on based on the conversation so far.

pylons.g -> pylons.app_globals (it definitely needs to self-document better)

The 'h' name is fine as is.

Instead of context, it'd be self-documenting if it was tmpl_context, yes, I know, even longer. Those uncomfortable with it would import it as 'c' and continue merrily along, those who don't like the smell of 'c' could keep it tmpl_context. The docs would show it being imported as 'c' in the controller, so its very clear that its both the tmpl_context, and how it became 'c', should someone not like that (and one letter vars definitely rub people the wrong way in Python, despite their convenience).

The import * should definitely go. I'm still leaning to having a few explicit imports in the controller, with commented out ones, rather than import proj.lib.base as base, and have base.XXX stuff all over the place.

So for the new controller template:

import pylons.tmpl_context as c
from pylons import render, request, response, session
# from pylons.controllers.util import abort, redirect_to, url_for

from yourproj.lib.base import BaseController


This ties up the vast majority of controller use, and the user can import anything else they need. That look good?

Most people don't regularly use the pylons.app_globals, so I see no reason to include them in the default controller template.

Cheers,
Ben

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to