Metaclass with name overloading.

Carlos Ribeiro carribeiro at
Tue Sep 28 18:38:30 CEST 2004

On Tue, 28 Sep 2004 14:37:31 +0200, Alex Martelli <aleaxit at> wrote:
> Carlos Ribeiro <carribeiro at> wrote:
>    ...
> > Generic templating mechanisms start as simple variable substitution
> > engines, but as they start to be used, there's the need to add control
> > structures (if, for, etc); it's also needed to provide more ways for
> > the template to communicate with the main program, exchanging
> > variables and values. At this point, wouldn't be better to write all
> > templates in the main programming language of the system?
> At this point, your templating is not declarative -- it's imperative.
> Like everything in Python, btw -- not ONE 'declarative' in sight (except
> the 'global' statement, which is part of what makes it a wart;-).

I knew I should have taken more time to write that paragraph :-) The
way I'm writing my code "reads" more like declarative code than
imperative. One can surely argue with my lack of academic rigour. I
think that I'm writing "declarative" code because I'm using class
declarations to create complex, hierarchic data structures. I want to
state __what it is__, not state __how it should be done__ step by

Your comment also made me realize a point that should be highlighted.
Normal templates [1] are clearly imperative, and that's part of my
problem with them. But complex object-oriented structures, although
including code (in the form of methods and descriptors) are much more
dynamic than a simple template. Better than this -- normal templates
are inherently sequential and imperative in the way they're written.
Object oriented structures are much more flexible in this respect.
[1] I stress the term "normal templates" because I'm focusing on
standard, run-of-the-mill templating systems.

> There IS a case for purely declarative stuff _embedding_ Python code,
> like's "blam" (purely informal name, as Strakt's marketing
> may lot like it, we just can't keep saying "Business Logic Module
> Language" forever;-) does for (basically) ERD + actions/triggers.  The
> embedding makes the whole non-declarative, of course.  But the
> declarative part can still be way prettier than it would be if it wasn't
> a separate language, e.g. it could use such keywords as 'entity',
> 'relation', 'attribute' and the like...

In the end, you've raised another interesting point -- on the whole,
my current approach is not purely declarative. It's rather a mix of
imperative and declarative, but with a mostly declarative
infrastructure holding things together.

Carlos Ribeiro
Consultoria em Projetos
mail: carribeiro at
mail: carribeiro at

More information about the Python-list mailing list