Metaclass with name overloading.
carribeiro at gmail.com
Tue Sep 28 12:45:43 CEST 2004
On 28 Sep 2004 09:47:51 +0200, Jacek Generowicz
<jacek.generowicz at cern.ch> wrote:
> Carlos Ribeiro <carribeiro at gmail.com> writes:
> > On 27 Sep 2004 13:33:33 +0200, Jacek Generowicz
> > <jacek.generowicz at cern.ch> wrote:
> > > I was wondering whether it would be possible to achieve this by
> > > forcing Python to use some dicitonary proxy (which accumulates
> > > values, rather that keeping just the last value to be associated
> > > with a key), instead of dict, when executing the class definiton?
> > No, you can't, and it's not just a parser issue. Python uses direct
> > C calls to the native dict type. It's hard coded,
> I feared this would be the case.
> > p.s. In the particular case of the original poster, I'm wondering
> > what kind of application did he had in mind.
> A standalone, lightweight SWIG-like tool, in this case. But in
> general, I've had cause to wonder about declarative syntaxes in Python
> every now and then.
I'm also exploring declarative alternatives for a lot of stuff in
Python. It started explicitly as an experiment, mainly because I could
not rationally explain why I did 'feel' that it was the right approach
for a class of applications: form definitions, reports, webpage
templates, etc. Now I think that I'm beginning to get a better
understanding that allows me to articulate better *why* should I
(ab)use Python for declarative programming, instead of using a data
driven approach with XML, or creating my own mini-declarative
language. In short, the argument goes like this:
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?
> Thanks, to all who contributed ideas to the thread, particularly Alex,
> Thomas and Lenard.
I learned a lot through this thread. As a matter of fact, I used your
problem as an exercise on decorators :-) And I think that, while still
exploring and making some (dumb) mistakes, I'm beginning to feel
comfortable with the more esoteric introspection features of Python.
After looking Lenard example, I've come to think about other
alternatives. There are a some interesting things that can still be
done, some even more esoteric than all stuff that we've done so far. A
generic solution for this problem would greatly simplify my own
search, and I'll keep looking for it.
Consultoria em Projetos
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com
More information about the Python-list