Re: [SQLObject] Proposal: change .get(int) to .get_id(int)

[Luke O. <lu...@me...>]

Quoting Mike Watkins <li...@mi...>:

> Proposal: change .get(int) to .get_id(int)
>
> It would be nice to be able to add common pythonic methods to our
> SQLObject objects without running into collisions. i.e. for a dict-like
> object, it might be nice to hand a SQLObject instance which has

Just so we're all on the same page here, not an SO *instance*, but an SO class.

I can see the naming clash, although there's a lot to implement to adapt an SO
class to a dictionary interface - with some conceptual mismatches in my mind.
Do you really need it to act like a dictionary, or do you just like the
semantics of the dict.get() call (retreive on whatever you choose as key, for
instance, or the optional default param)? I guess I'm having a hard time
seeing the times when I would be able write code that worked interchangely on
dicts and SO classes, even if the get() naming conflict is resolved.

> Occasionally I've got a SQL relation where I don't want anyone to
> think/see or smell the serial int identity column - a unique string as
> key is what I"m after, very dict like.

alternateID, People.byName() style? I personally use this a good amount, but I
don't think it would take much work to hide this as if it were the default
.get() retrieval. (So long as those semantics are clear in the code.)


class Person(SQLObject):
  name = StringCol(alternateID=True)

Person.get_id = Person.byName

Would work. Even moreso, what if the current functionality of SQLObject.get is
renamed to _SO_get (or whatever private name), and internal functions (such as
_SO_fetchAlternateID) call that. Then the default SQLObject.get keeps the
current semantics but just calls cls._SO_get(). That would allow you to
override get() to behave like a dict if you want without messing up the
internals of your objects, or to do

Person.get = Person.byName

to stick to the current interface but use names as retrieval keys instead of
the actual database ids. (Or to do things like the column overrides,
performing pre/post processing during object retrieval)

- Luke