Breaking out Django templates into a standalone library
Tom Tobin
part from my direction ^_^), I floated the idea that perhaps my
concern over autoescaping was pointed in the wrong direction — that it
might be time to split Django's template module out into a standalone
library. The idea has been raised before, but discussion always hits
the point of "good idea, but a PITA ..." and a combination of time
constraints and the bystander effect kick in to shelve it.
Since I've been championing the use of Django's template library as a
general purpose library, and spending plenty of time in the guts of
the template code while writing the taghelpers module, I may as well
step up and offer to do this. And no, I don't want another Jinja [1]
[2]; I want a Django template library that's still distributed as part
of Django, in the Django namespace, and available in its separate
split-off form from the Django website, similar to how the various
Twisted modules are distributed [3].
I know there are various obstacles here, the largest one being the use
of Django settings in the template code — but nothing looks
unsurmountable.
I'd ideally like to have this done in time for Django 1.0, and to
ensure stable releases in line with future Django releases.
So ... thoughts?
[2] Not to disparage Jinja; I just have a different goal in mind.
Malcolm Tredinnick
> At the end of the angsty autoescaping thread (said angst in no small
> part from my direction ^_^), I floated the idea that perhaps my
> might be time to split Django's template module out into a standalone
> library. The idea has been raised before, but discussion always hits
> the point of "good idea, but a PITA ..." and a combination of time
> constraints and the bystander effect kick in to shelve it.
That isn't my recollection, and I was involved in some of those previous
discussions. The main argument is that it isn't a really good idea, for
reasons outlined below. You don't address why we would want to do this.
What's the really compelling use-case that isn't already handled by
installing Django and just using the templating code with standalone
configure (via settings.configure())? Package size isn't the argument --
Django is relatively small and you don't gain that much by isolating the
templates, once you include all the supporting stuff, since the bulk of
the disk usage of Django is in the PO files.
> Since I've been championing the use of Django's template library as a
> general purpose library, and spending plenty of time in the guts of
> the template code while writing the taghelpers module, I may as well
> step up and offer to do this. And no, I don't want another Jinja [1]
> [2]; I want a Django template library that's still distributed as part
> of Django, in the Django namespace, and available in its separate
> split-off form from the Django website, similar to how the various
> Twisted modules are distributed [3].
>
> I know there are various obstacles here, the largest one being the use
> of Django settings in the template code -- but nothing looks
> unsurmountable.
The main reason we implemented standalone configuration (via
settings.configure()) was so that you could use the template library in
isolation. At the time (starting about 18 months ago), we had a bit of a
debate about where to include the defaults (in django.conf or
django.templates, etc) and decided the current approach wasn't really
hindering anything and meant there was only one spot you had to look for
things.
> I'd ideally like to have this done in time for Django 1.0, and to
> ensure stable releases in line with future Django releases.
>
> So ... thoughts?
Please, no.
The main problems are
(1) It's not really worth it, since installing all of Django and then
just not using part of it is easy -- it's not a huge package after all.
Experience has shown that the Twisted split hasn't been a no-brainer
success. By and large, the easiest thing to do, even with Twisted, is
install everything and just use the bits you need. Otherwise you spend
ages wallowing around trying to work out which bits you do need. When it
comes to packaging for distros, Twisted either has to be done as one
mega-package or something like TurboGears or Pylons as a combination of
a bunch of individual packages (usually the latter). That latter
situation is a packaging strategy Django intentionally avoids and it
will make downstream packaging after 1.0 much easier. People just have
to install django-1.0.
(2) It leads to problems with debugging, installing, setting up and
helping people when they have both the separate library and the whole
Django package installed. Which template portion is being used, etc? Are
they up-to-date? Are they interfering with each other? If everything's
in one package, then we only have to worry about the people who have
multiple Django versions installed and that's much easier to debug.
(3) If the goal is that django-core will use django-templates, we are
going down the Pylons path. Batteries included is a good philosophy for
something the size of Django, though. If the goal is that django-core
will duplicate django-templates, you have problems (1) and (2), above.
Regards.
Malcolm
--
Save the whales. Collect the whole set.
http://www.pointy-stick.com/blog/
Adrian Holovaty
> Since I've been championing the use of Django's template library as a
> general purpose library, and spending plenty of time in the guts of
> the template code while writing the taghelpers module, I may as well
> step up and offer to do this.
This would be great, as long as you could figure out how to make it
backwards compatible. Thanks for volunteering! :-)
Here are some broad goals/thoughts, IMHO:
* Users of Django the framework should not be affected in any way.
* Ideally we should not have to maintain two versions of the codebase.
* Figuring out the settings stuff could be tricky.
* Consider the case of people who download and use the standalone
template system, then decide to install the whole framework. It would
be nice (but not essential) if they didn't have to have conflicting
versions of the template library installed on their systems. I don't
know anything about the way Twisted modules are distributed (which is
what you alluded to) -- do they have a nice way of solving this
problem?
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Adrian Holovaty
Well, then -- I did a great job of contradicting your e-mail, with my
own message. :-)
Malcolm Tredinnick
> On 8/7/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> > Please, no.
> >
> > The main problems are
>
> Well, then -- I did a great job of contradicting your e-mail, with my
> own message. :-)
Nah .. you were just using a softer stick. You highlighted the same
problems (but arrived at a different conclusion). :-)
I want to hear the use-case first. I may change my mind, but nobody's
come up with a good reason so far.
Cheers,
Malcolm
--
If at first you don't succeed, destroy all evidence that you tried.
http://www.pointy-stick.com/blog/
James Bennett
> I want to hear the use-case first. I may change my mind, but nobody's
> come up with a good reason so far.
I think Tom's primary goal is to provide an easy path to use the
Django template system in non-HTML contexts without having to worry
about autoescaping (since the standalone library could leave it off or
configurable at a higher level while Django as a whole could force
autoescaping on), and I can see that looming large; there are already
a number of interesting uses for the template system that don't
involve HTML at all :)
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Malcolm Tredinnick
> On 8/7/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> > I want to hear the use-case first. I may change my mind, but nobody's
> > come up with a good reason so far.
>
> I think Tom's primary goal is to provide an easy path to use the
> Django template system in non-HTML contexts without having to worry
> about autoescaping (since the standalone library could leave it off or
> configurable at a higher level while Django as a whole could force
> autoescaping on), and I can see that looming large; there are already
> a number of interesting uses for the template system that don't
> involve HTML at all :)
I want to hear a *good* reason. Having to use or not use a particular
single tag, once, isn't a good reason for all that extra work and
maintenance effort. If this is all coming out of the autoescape
conversation then.. well... it's disappointing, to say the least.
Malcolm
--
Everything is _not_ based on faith... take my word for it.
http://www.pointy-stick.com/blog/
Gary Wilson
> I want to hear the use-case first. I may change my mind, but nobody's
> come up with a good reason so far.
How about looking at things from the opposite direction? Yes, it would
be nice if the Django template system could be more easily used
standalone, but by doing this it would also most probably allow Django
to plug in other template engines more easily.
This feature could be a deciding factor for folks who would use Django
"if only I could use my favorite XML-based templating system" or those
switching from another framework with existing templates that they
wouldn't want to totally rewrite.
Also, food for thought, it seems that the "merger" of TurboGears and
Pylons [1][2][3] sparked the creation of the pytemplates google group
[4], where interested parties have been talking about creating a
standard API with plugins for various template engines.
Gary
[1]
http://compoundthinking.com/blog/index.php/2007/03/05/merging-turbogears-and-pylons/
[2]
http://www.oreillynet.com/onlamp/blog/2007/06/python_web_application_framewo.html
[3]
http://www.blueskyonmars.com/2007/06/27/turbogears-2-a-reinvention-and-back-to-its-roots/
[4] http://groups.google.com/group/pytemplates
Malcolm Tredinnick
> Malcolm Tredinnick wrote:
> > I want to hear the use-case first. I may change my mind, but nobody's
> > come up with a good reason so far.
>
> How about looking at things from the opposite direction? Yes, it would
> be nice if the Django template system could be more easily used
> standalone, but by doing this it would also most probably allow Django
> to plug in other template engines more easily.
Again, this needs an answer to the question of what does "more easily"
mean. Currently, you import django.template, django.conf and make sure
you call django.conf.configure(...) prior to using the template stuff.
There's limited scope for streamlining there.
Maybe adding something like
django.conf.default_do_nothing_template_setup() reduces the complexity
and this was something we discussed as a possible enhancement when
django.conf.configure() was implemented. However, it won't be one size
fits all (if you ever want to use template loaders -- via extends or
include tags -- some configuration is required). It could live in the
django.template namespace so that only django.template needed to be
imported. Aside from that, what else comes wrapped up in this new
"easier" system.. I'm not trying to be difficult here; I genuinely don't
understand these perceived benefits and it's not for want of using the
system or thinking about the problem space.
> This feature could be a deciding factor for folks who would use Django
> "if only I could use my favorite XML-based templating system" or those
> switching from another framework with existing templates that they
> wouldn't want to totally rewrite.
Unconvinced.
The sort of questions I would ask (and answer) are:
Can Django's templating system be used standalone at the moment
without difficulty? Yes.
Can other templating systems already be used with Django without
needing to write lots of extra code? Yes.
We added the necessary features (configuration without requiring
DJANGO_SETTINGS_MODULE)for isolated template usage 18 months ago. What
needs to be made easier? Why can't whatever those changes are be done
without splitting?
How to make plugging in separate template engines easier is also
interesting, but, again, not particularly contingent on a split. It's
already possible and not particularly difficult: writing an appropriate
render_to_response makes things easier for some people, but by and
large, it's pretty much the same code you write now. When I did this for
a client late last year (using Cheetah throughout), the only real mod I
needed to make was a way to get a snapshot of the current Context's
top-layer of dictionary keys and values so that I could pass a real
dictionary around. Replacing the Context class with my own variant at
runtime fixed that. Including the method in core would help, though.
So the focus is on whether we need to make this easier and how. What
needs to be done there?
I really worry that we shouldn't be trying to reinvent Turbogears here.
If somebody wants plug-and-change-their-mind components, it's already
spelt "Turbogears" or "Pylons". Adding the necessary stuff to integrate
Django templates with Turbogears can't be that difficult (since it can
already be used standalone).
Please let's make sure we're solving worthwhile problems and trying to
solve the same problems. None of the stuff you've mentioned, Garry,
requires splitting templates off from Django. They're worthwhile things
to do on some level, but we can pretty much already do most of what is
needed, in practice.
It comes back to my original question for me: what can't be done now or
with a couple of small tweaks that can be done after the much more
disruptive change of splitting out the template system?
Regards,
Malcolm
--
Why can't you be a non-conformist like everyone else?
http://www.pointy-stick.com/blog/
Tom Tobin
> > At the end of the angsty autoescaping thread (said angst in no small
> > part from my direction ^_^), I floated the idea that perhaps my
> > concern over autoescaping was pointed in the wrong direction -- that it
> > might be time to split Django's template module out into a standalone
> > library. The idea has been raised before, but discussion always hits
> > the point of "good idea, but a PITA ..." and a combination of time
> > constraints and the bystander effect kick in to shelve it.
>
> That isn't my recollection, and I was involved in some of those previous
> discussions. The main argument is that it isn't a really good idea, for
> reasons outlined below. You don't address why we would want to do this.
Err, to make it more straightforward for others to use *just* the
templating system?
> What's the really compelling use-case that isn't already handled by
> installing Django and just using the templating code with standalone
> configure (via settings.configure())? Package size isn't the argument --
> Django is relatively small and you don't gain that much by isolating the
> templates, once you include all the supporting stuff, since the bulk of
> the disk usage of Django is in the PO files.
You're right, package size *isn't* the argument; when it comes down to
it, many people don't like installing stuff they have zero intention
of using.
> > Since I've been championing the use of Django's template library as a
> > general purpose library, and spending plenty of time in the guts of
> > the template code while writing the taghelpers module, I may as well
> > step up and offer to do this. And no, I don't want another Jinja [1]
> > [2]; I want a Django template library that's still distributed as part
> > of Django, in the Django namespace, and available in its separate
> > split-off form from the Django website, similar to how the various
> > Twisted modules are distributed [3].
> >
> > I know there are various obstacles here, the largest one being the use
> > of Django settings in the template code -- but nothing looks
> > unsurmountable.
>
> The main reason we implemented standalone configuration (via
> settings.configure()) was so that you could use the template library in
> isolation. At the time (starting about 18 months ago), we had a bit of a
> debate about where to include the defaults (in django.conf or
> django.templates, etc) and decided the current approach wasn't really
> hindering anything and meant there was only one spot you had to look for
> things.
That doesn't mean we can't re-approach the idea, assuming it was done well.
> > I'd ideally like to have this done in time for Django 1.0, and to
> > ensure stable releases in line with future Django releases.
> >
> > So ... thoughts?
>
> Please, no.
>
> The main problems are
>
> (1) It's not really worth it, since installing all of Django and then
> just not using part of it is easy -- it's not a huge package after all.
>
> Experience has shown that the Twisted split hasn't been a no-brainer
> success. By and large, the easiest thing to do, even with Twisted, is
> install everything and just use the bits you need. Otherwise you spend
> ages wallowing around trying to work out which bits you do need. When it
> comes to packaging for distros, Twisted either has to be done as one
> mega-package or something like TurboGears or Pylons as a combination of
> a bunch of individual packages (usually the latter). That latter
> situation is a packaging strategy Django intentionally avoids and it
> will make downstream packaging after 1.0 much easier. People just have
> to install django-1.0.
People will *still* be able to just install django-1.0. Perhaps I
didn't explain the packaging situation quite as clearly as I could
have; the Django templating system would *still* be distributed as
part of Django, in the django.template namespace. No separate package
required. Batteries included. The Twisted analogy was meant to draw
a parallel more with the namespacing than enforced separation (and
even for Twisted, there's always the "Sumo" package).
> (2) It leads to problems with debugging, installing, setting up and
> helping people when they have both the separate library and the whole
> Django package installed. Which template portion is being used, etc? Are
> they up-to-date? Are they interfering with each other? If everything's
> in one package, then we only have to worry about the people who have
> multiple Django versions installed and that's much easier to debug.
See point above.
> (3) If the goal is that django-core will use django-templates, we are
> going down the Pylons path. Batteries included is a good philosophy for
> something the size of Django, though. If the goal is that django-core
> will duplicate django-templates, you have problems (1) and (2), above.
Partially see point above; I intend that the Django template system
continue to be distributed alongside Django, and for the Django
packaging system to pull in the Django template library. No
duplication is involved; there would be only one place for
django-template code development.
Tom Tobin
>
> This would be great, as long as you could figure out how to make it
> backwards compatible. Thanks for volunteering! :-)
>
> Here are some broad goals/thoughts, IMHO:
>
> * Users of Django the framework should not be affected in any way.
>
> * Ideally we should not have to maintain two versions of the codebase.
These two points are certainly in mind; see my reply to Malcolm's
reply. In short, Django templates would still be distributed as part
of Django, "batteries included" and all, and would also be available
as a standalone package. There would be only one codebase, which
would get pulled in during packaging. svn externals could be used for
the standard "work out of an svn checkout" case.
> * Figuring out the settings stuff could be tricky.
Absolutely agreed; this is where most of the fun is going to come in. ^_^
> * Consider the case of people who download and use the standalone
> template system, then decide to install the whole framework. It would
> be nice (but not essential) if they didn't have to have conflicting
> versions of the template library installed on their systems. I don't
> know anything about the way Twisted modules are distributed (which is
> what you alluded to) -- do they have a nice way of solving this
> problem?
I'd ideally like the Django installer to detect if django.template was
already on the system, and drop Django into the same spot. As far as
versioning, Django should check for a minimum version of Django
templates (i.e., the version at the time of that Django's release),
assuming it was already installed on the system; if it detected a
version below the minimum, it would be nice for the installer to offer
to simply overwrite the entire django namespace.
I don't recall offhand how Twisted handles versioning; we can probably
get away with a fairly simple system, since there would only be a
one-way dependency and only in cases where a user installed standalone
Django templates *before* installing full Django (again, Django
templates would come with Django in the ordinary case).
Malcolm Tredinnick
> On 8/7/07, Adrian Holovaty <holo...@gmail.com> wrote:
> > * Figuring out the settings stuff could be tricky.
>
> Absolutely agreed; this is where most of the fun is going to come in. ^_^
A couple of other areas are going to be at least equally as
interesting...
(1) Splitting out the pieces from django.utils that are just used by the
template system and moving them under django.templates (preferably in a
backwards compatible way, but that's probably easy once you work out the
bits).
(2) Internationalization is going to be the real creative problem:
you'll need to ship a duplicate of django.utils.translation somehow.
Also split out the template (and template support code) related messages
from the PO files and ship the appropriate message catalogs. This can
possibly be done with a bit of gettext hackery. Splitting the
translations into two source files in each case files is a bit unfair on
the translators, I wouldn't want to do that. There will be a number of
duplicate strings and twice as many files for them to maintain.
Other areas of duplication are things like the local flavor data and
other locale-dependent information. It's pretty likely that locale-aware
formatting and validation logically belong together (for maintenance and
testing purposes, for a start) and the presentation side is used in more
places than just template rendering.
The amount of support baggage needed is non-trivial once you factor in
i18n support and shared code from places like django.utils, which is why
I'm unconvinced this achieves any real benefit. It's like somebody
hoping to trim timezone files form their laptop just because they only
live in the Australia and don't expect to travel, or worrying that
Python installs the array module when they aren't likely to use it. The
fact of life is that people install small amounts of code they don't use
all the time and don't ever give it a second thought. The extra overhead
just to ship everything is truly minor.
Regards,
Malcolm
--
Experience is something you don't get until just after you need it.
http://www.pointy-stick.com/blog/
James Bennett
> I'd ideally like the Django installer to detect if django.template was
> already on the system, and drop Django into the same spot. As far as
> versioning, Django should check for a minimum version of Django
> templates (i.e., the version at the time of that Django's release),
> assuming it was already installed on the system; if it detected a
> version below the minimum, it would be nice for the installer to offer
> to simply overwrite the entire django namespace.
In theory, setuptools can do this sort of "namespace" trick, but the
system which handles that has always seemed a little clunky to me.
If you manage this feat with the template system, how would you feel
about trying the same trick with other components? If there *is* a
clean solution (and I'm not sure there is), it'd be nice to offer,
say, the ORM as a standalone component (if nothing else it'd provide a
permanent answer to the "how do I use the ORM without writing a web
app" question).
Though I think Malcolm's right in that we've already done what's
technically *necessary* to allow the template system to be used
standalone, I'd be interested to see if we can make it more convenient
to do so (though if we'd done that from the start, Jinja might never
have happened, and I know some folks who are fond of it). All the
stuff we do at World Online with non-web-app uses of the template
system take place on boxes that already have a full Django stack
installed, so it wouldn't really affect us either way, but it couldn't
hurt to see if we can make it easier for folks who want to just use
templating.
My biggest worries, though, aren't actually the settings, because it'd
be easy enough to provide some hook for manually specifying a loader
and directories (context processors aren't too difficult because
RequestContext already accepts a keyword argument for those):
1. The search path for tag libraries is still the magic
"django.templatetags" module; either that'd have to change, or the
package would have to provide both django.template and
django.templatetags.
2. All the useful bits for unit-testing templates live in django.test,
and all the actual tests for the template system itself live in
tests/regressiontests/templates outside even the "django" namespace.
Solving that one may be trickier than it looks ;)
James Bennett
> A couple of other areas are going to be at least equally as
> interesting...
I hereby amend my list of worries to include Malcolm's ;)
Robert Coup
On 8/8/07, Tom Tobin <kor...@korpios.com> wrote:
> I'd ideally like the Django installer to detect if django.template was
> already on the system, and drop Django into the same spot. As far as
> versioning, Django should check for a minimum version of Django
> templates (i.e., the version at the time of that Django's release),
> assuming it was already installed on the system; if it detected a
> version below the minimum, it would be nice for the installer to offer
> to simply overwrite the entire django namespace.
In theory, setuptools can do this sort of "namespace" trick, but the
system which handles that has always seemed a little clunky to me.
My concern would be when "setup.py install" does too much clever trickery and starts conflicting with distribution packages. You install django-templates via setup.py and it ends up in /usr/local/python2.5/site-packages, then you install django & templates from your distribution and presto, your django install now pulls in templates from a different version.
I know its a contrived case and there are many other opportunities for making a mess of a system, but i'd be concerned about setuptools needing to do anything but the basics.
Rob :)
Tom Tobin
I'll definitely be looking into as many corner cases as possible with
installing Django on top of an existing Django-templates install; I
really do want it to be as painless as possible for those who might
try Django after playing with just the templating system.
Adrian Holovaty
> interesting...
Malcolm has made some *really* good points throughout this thread, and
I'm convinced that going down this path would be a not-so-good idea.
My opinion on it at this point could be be classified as "blah," or
possibly "meh."
I have a feeling that the underlying reason for wanting a standalone
django.template, deep in our collective subconscious, is that the
settings.configure() thing is inelegant. I shouldn't have to configure
anything just to use the template library. I should be able to import
django.template.Template and django.template.Context, and use them
immediately to render some text.
Plainly put, the system should work without requiring configuration.
Sure, if you need template loading support, maybe then we would
require the settings to be configured. Sure, if you need
internationalization, maybe then we would require configuration. But
the barebones, common case of "render this template with this context,
with no internationalization" needs to work without having to mess
with configuration.
Here's what currently happens.
>>> from django.template import Template, Context
>>> t = Template('hello')
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "django/template/__init__.py", line 167, in __init__
if settings.TEMPLATE_DEBUG and origin == None:
File "django/conf/__init__.py", line 28, in __getattr__
self._import_settings()
File "django/conf/__init__.py", line 55, in _import_settings
raise EnvironmentError, "Environment variable %s is undefined." %
ENVIRONMENT_VARIABLE
EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined.
I think some work in this area *would* be worth it, as it would make
it easier to use Django's template language in a standalone setting
but would stop short of being a complete reorganization of the code
and architecture.
Tom Tobin
>
> On 8/8/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> > A couple of other areas are going to be at least equally as
> > interesting...
>
> Malcolm has made some *really* good points throughout this thread, and
> I'm convinced that going down this path would be a not-so-good idea.
>
> My opinion on it at this point could be be classified as "blah," or
> possibly "meh."
>
> I have a feeling that the underlying reason for wanting a standalone
> django.template, deep in our collective subconscious, is that the
> settings.configure() thing is inelegant. I shouldn't have to configure
> anything just to use the template library. I should be able to import
> django.template.Template and django.template.Context, and use them
> immediately to render some text.
I think there's a good psychological / community case to be made for
making django.template available standalone; as I put it earlier, many
people just don't like importing stuff they don't intend to use, no
matter how small it may be byte-wise. Requiring someone to install
Django just to use the templating system is going to prevent them, in
various cases, from bothering at all.
> I think some work in this area *would* be worth it, as it would make
> it easier to use Django's template language in a standalone setting
> but would stop short of being a complete reorganization of the code
> and architecture.
I don't really intend for things to get *that* reorganized; packaging
and whatnot aside, my goal is for django.template to work without the
rest of Django installed.
Adrian Holovaty
> making django.template available standalone; as I put it earlier, many
> people just don't like importing stuff they don't intend to use, no
> matter how small it may be byte-wise. Requiring someone to install
> Django just to use the templating system is going to prevent them, in
> various cases, from bothering at all.
If this is your primary reason for suggesting django.template be a
standalone library, it doesn't win me (and, it's safe to say, Malcolm)
over. I am in 100% agreement with Malcolm that saying "We only
distribute one version of Django" is reasonable.
For what it's worth, here's a personal narrative. I am extremely anal
about Python packages. When a setuptools-ish package craps all over my
site-packages directory, installing 15 packages that I
may-or-may-not-use-but-we'll-install-them-just-in-case, I'm not happy.
I see it as a gross invasion of my personal space, like the jerks who
insert advertisements on my car's windshield while I'm parked at a
grocery store. But I do not care if a *single* package includes more
code than I want to use.
What I *do* think is worth fixing is allowing the template system to
be used on its own, for the simple, common case, without having to
configure stuff. This is what I was trying to explain in my last
e-mail. Tom, if we solved that, would you be happy?
In short: I want to understand your goal. If you want to offer a
smaller download, then that doesn't justify the hassle of making this
change. If you want us to make it easier to use the template system
without configuration, let's talk.
Tom Tobin
> be used on its own, for the simple, common case, without having to
> configure stuff. This is what I was trying to explain in my last
> e-mail. Tom, if we solved that, would you be happy?
>
> In short: I want to understand your goal. If you want to offer a
> smaller download, then that doesn't justify the hassle of making this
> change. If you want us to make it easier to use the template system
> without configuration, let's talk.
Forget I suggested anything. I don't really have the energy to keep
arguing here; it's tiring when everything I suggest gets throughly
shot down (and that's besides whether said shooting-down is valid or
not; even if it's perfectly valid, it's *still* tiring). I'm not
helping, so I'll move along.
limodou
I agree!
--
I like python!
UliPad <<The Python Editor>>: http://code.google.com/p/ulipad/
My Blog: http://www.donews.net/limodou