On 2005-09-15, Jonathan Ellis <[EMAIL PROTECTED]> wrote: > James wrote: >> I actually like the framework to reflect on my database. I am more of a >> visual person. I have tools for all my favorite databases that allow me >> to get a glance of ER diagrams and I would rather develop my data >> models in these tools rather than in code. Further more I rather like >> the idea of parsimonious use of code (which is probably why I use >> Python in the first place) and do not really like manually specifying >> data schemas in code as much as possible. >> >> Is some familiar with a Python Framework that builds by reflection. > > PyDO (http://skunkweb.sourceforge.net/pydo2.html) is a Python ORM tool > that does this well (*cough* better than sqlobject *cough*).
As the current PyDO dev, I won't make the same comparative value judgement as Jonathan here, not out of reticence, but lack of conviction -- SQLObject is quite excellent, and for all I know better than PyDO in execution -- but a comparison I would make is that PyDO is different from ORMs like SQLObject (and even more so, from ActiveRecord) in that it assumes that the database precedes the object layer, chronologically and/or in significance, and that the database schema shouldn't need to conform much to a particular ORM's expectations, reasonable as they may or not be. The most obvious differences are that SQLObject expects tables to have an "id" integer column, and doesn't support multi-column candidate keys; PyDO doesn't make such demands. So, similar as they are, in orientation these libraries are somewhat different beasts. I have mixed feelings about automagical schema introspection. PyDO supports it, and will probably do so increasingly robustly if people use it. But part of me feels that "explicit is better than implicit" may win out over DRY here, because the ORM layer and the db layer exist in different realms, and if the ORM layer adapts silently to changes in the db layer, other code is likely to fail in unpredictable ways, including silently, whereas an explicit declaration of what fields are in a table, for instance, will fail with a hard error. But maybe this is anal retentiveness, akin to a need for strong typing. js -- Jacob Smullyan -- http://mail.python.org/mailman/listinfo/python-list