We're definitely on the same wavelength, Alan. :-) Alan Gauld wrote: > "Stephen McInerney" <[EMAIL PROTECTED]> wrote > > >> Eric, you misunderstood my point. >> I said you make a **token** assignment in the class defn simply >> to do two things: >> - 1) identify all the members in one place >> - 2) annotate each member's type, as much as you can >> > > I'm sure Eric can explain for himself but what I think he was saying > was that his classes define themselves at runtime. They read the > names of the fields and type information from the database metadata > and create the attributes accordingly. Thus he doesn't know what > his class attributes will be until the program runs. He may not even > know the names of his classes until he reads the database > tablenames. > > This is exactly the kind of tricky coding that is possible in a > dynamic > language which is next tio impossible in static compiled code, unless > you write your own 'little language interpreter' inside the compiled > program. This kind of abstract meta programming is extremely tricky > to get right but at least it's possible in something like Python. > But it makes analyzing the code very complex since much of the > working code is being created by the config code at runtime. > > I've never actually tried this in Python but have done similar things > in Lisp. In C++ you usually have to create classes in advance for > every possible eventuality then use a factory class (or big switch > statement) to create the desitred instances. That's a lot of excess > code which is still less reliable and robust. > > Of course I could be misreading Eric's intent... > > Alan G. > > > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor >
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
