Carlos Ribeiro wrote:
> On Fri, 28 Jan 2005 18:53:30 -0600, Ian Bicking <ianb@...> wrote:
>>Carlos Ribeiro wrote:
>>>Humm. A __getitem__/__setitem__ there would not do any harm IMHO. I
>>>hope ou reconsider :-) But at the same time, an adapter may be enough
>>>for this purpose.
>>A dictionary interface is just too ambiguous. I can appreciate that it
>>comes with a number of useful methods (like keys(), __contains__, etc)
>>that feel missing compared to normal attributes. But  implies a level
>>of dynamicism that I think isn't good.
> I'm not sure I understand what do you mean with 'ambiguous'. One
> possible concern is that access through the  interface will happily
> create new (key, item) pairs. In this case, a custom __setitem__ can
> be designed so it traps it and raises an KeyError instead.
From the outside, what does it mean when you use ? Dictionaries are
benign structures, you put things in and take them out, and they just
sit there. SQLObject instances aren't benign in the same way, they
don't just hold data. If you had an interface that looked like
my_row.columns['column_name'], that would be okay, because the .columns
makes it clear just what you are getting and setting. But I don't like
a dictionary interface where it isn't clear what you are fetching from.
>>>One potential application for this interface is to build automated
>>>tools around SQLObject. For instance: report generators, form
>>>generators, and the kind of scaffolding stuff that Rails is now famed
>>>for. Of course, one can dive into SQLObject internals... but better
>>>introspection methods would be helpful. A dict-like interface is
>>>natural because __getitem__ style access is more convenient in this
>>>scenario, to retrieve the necessary fields. BTW, I found myself using
>>>getattr more often than I would care to admit.
>>I would agree there should be more clear, public methods for reflection
>>in SQLObject, but I don't think there's anything wrong with getattr, and
>>I don't think the dictionary interface is ultimately complete enough or
> I think I expressed myself badly; there's nothing wrong with getattr
> per se... but on the other hand, I believe that access via the
> __getitem__ interface is still more convenient. But that may be a
> matter of personal opinion. I think that, while we can overload
> __getitem__ so it exposes only a few attributes of the object (in
> SQLObject's case, just the columns), it's more difficult to do the
> same with a getattr interface, which involves automatic lookup on the
> class, superclasses, etc.
That's a plus and a minus. For instance, if you have a derivative value
that you allowed to be set, it's nice if it is a peer of the actual
column. Right now the commonality is around attributes and overriding
attributes. As the column-related metadata is extended, it would be
nice to continue to allow hooks to add non-column attributes to that
> An example may help to clarify things: I would welcome the ability to
> iterate over the columns of a SQLObject using iteritems() to build a
> report, or a form, as in:
> for colname, value in Person.iteritems():
> print "%s: %s" % colname, value
> The main advantage is familiarity: the iteritems() interface is well
> know. It can return only the columns defined in the object, and that
> seems to be intuitive enough for users to understand.
I'd rather that look like:
for colname, value in person.sqlmeta.columns.items():
print '%s: %s' % (colname, value)
Because there's actually a whole slew of methods for reflection that
would be useful, and I actually don't think these column values would be
the most important ones.
> That said, I think that's a very interesting discussion. Let's the
> issue rest a little bit; maybe we can gather more opinions... Best
> regards, and have a nice weekend!
Ian Bicking / ianb@... / http://blog.ianbicking.org