On Tue, 2003-05-20 at 06:55, Bud P.Bruegger wrote:
> I've been thinking about the API for dealing with relations.
>
> person.roles is just perfect.
>
> In addition, what about person.rolesWhere(<some condition>)
Well, you can create a select query to do this, but you have to specify
the join explicitly. Maybe with the interface below, it could look like
person.roles.select(condition).
> And instead of person.addRole(r), what about person.roles.append(r)
> and similarly, r.removePerson(p) as r.persons.remove(p)
I started on this path, where joins returned a result of some sort,
subclassing lists. But I realized I was getting to distracted at what
was an early point of development, so I didn't do it. I might make that
change yet. However, the result would look more like SelectResults, and
not a subclass of list.
> To be pythonic, everything should behave as much as a list as
> possible. So I started to play around with inheriting from list and
> looking at the hooks (see attached file). I was expecting that there
> was a single interface to setting and getting list items (namely,
> __getitem__ and __setitem__), but it seems that other ways of
> modifying the list such as l.extend() or l.append() don't internally
> fall back on __getitem__ and __setitem__.
I think it's easier to make it an iterable object, with list-like
methods, like SelectResults. Then if you want a list that doesn't
change underneith you, you just call list(person.roles).
Joins are also more like sets than lists, so that would be a better
interface model.
http://www.python.org/dev/doc/devel/lib/set-objects.html
> Also, someone could "recalculate" relationships and assign them:
> p.roles = throttleBack(p.roles)
I'm not sure I understand what you're thinking here.
Ian
|
