On Dec 30, 2:52 pm, Bruno Desthuilliers <bdesth.quelquech...@free.quelquepart.fr> wrote: > Aaron Brady a écrit : > > > On Dec 30, 11:16 am, prueba...@latinmail.com wrote: > (snip) > >> You really do like to reinvent the wheels do you? :-) Nothing wrong > >> with that. Just be aware that most people that really need what you > >> are proposing are probably already using mature feature rich libraries > >> for that. > > >>http://wiki.python.org/moin/HigherLevelDatabaseProgramming > > > Look at these options! Who invents the wheel? Naturally, I've had > > time to master every one. > > Oh, so that's why you propose to add yet another item to the list ?
Aha, so it is. Your criticism might seem harsh, but it has an advantage. It made me get the lead out, that is, think. Assuming I do want my Relation class to be backed by a full-fledged database, all I would need is an adapter to a Dee or Django object. The only restriction is, records have to be uniform types. (In many cases, this can be good, since relations are statically typed.) I recognize that on average, I'm only saving a little syntax. If I have a Student object and I want the classes s/he is in, the SQL isn't horrible. SELECT objectrep FROM Classes WHERE Student IS studentA //'IS' is not supported in SQL It returns a list of Class instances. The Python is better. studentA.getClasses() To make it fully dynamic, studentA.get( 'Classes' ) or studentA.get( Classes ) or studentA.cross( Classes ) would be closer to what I have in mind. If readers will permit a brainstorm, maybe one of the options will spark an idea. studentA and Classes studentA.intersection( Classes ) However, I want a list of classes, not a list of students, so I am not wanting a pure 'intersection' relation, that is, not a commutative one. Classes.get( studentA ) Classes and studentA #breaks commutativity of 'and' Classes.intersection( studentA ) The method will have to determine what field 'studentA' is supposed to match. -- http://mail.python.org/mailman/listinfo/python-list
