Re: [SQLObject] Export SOCol's in __all__

[Ian B. <ia...@co...>]

Barry Warsaw wrote:
> On Mon, 2005-01-10 at 15:08, Ian Bicking wrote:
> 
>>Barry Warsaw wrote:
>>
>>>One other thing, at the bottom of col.py, you export all subclasses of
>>>Col in sqlobject.col's __all__.  Should you also export all subclasses
>>>of SOCol too?
>>
>>No, because those classes should only be instantiated by the non-SO 
>>versions of the classes.
> 
> 
> Probably my naivete, but in my first attempt I subclassed
> SOMyDateTimeCol from SODateTimeCol, which I didn't get if I "from
> sqlobject.col import *".  Maybe I didn't need to do that, but I was just
> monkeypasting from the examples in col.py.

I added a docstring to help clarify this.

>>The point of the two classes is just so that the non-SO instances are 
>>relatively reusable, and are not bound to a specific name or SQLObject 
>>class.  So you could do:
>>
>>myDate = DateTimeCol(validator=toMxDateTime)
> 
> 
> Where does toMxDatTime come from?  That'd be a function I'd supply?

Yes, an exercise for the reader.

>>class A(SQLObject):
>>     created = myDate
>>
>>class B(SQLObject):
>>     created = myDate
>>
>>A.created and B.created are two separate SODateTimeCol instances.  Now, 
>>I don't know if anyone actually *does* that.  But anyway, that's the idea.
> 
> 
> Interesting, are they different instances because the metaclass does
> something magical?

Yes, the metaclass collects and munges all the Col objects it finds. 
That's really the only reason for the metaclass (that and a few things 
that keep subclasses and superclasses from inappropriately sharing data).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org