Re: [SQLObject] ezSqlObject convenience wrapper

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

On Mar 7, 2004, at 6:45 PM, Brad Bollenbach wrote:
> On Sunday, March 7, 2004, at 07:23  PM, David McNab wrote:
>
>> Brad Bollenbach wrote:
>>> It doesn't make any sense to create another module for this.
>>
>> I can't say I agree here.
>>
>> Wrapper modules are a great way to try out ideas.
>>
>> If the core package devs happen to like one or more of the ideas, 
>> they can always merge them in, or give cvs write access to whover 
>> wrote the wrapper.
>>
>> And if the core devs don't like the ideas, the wrapper writer gets to 
>> use the wrapped interface in his/her code regardless.
>>
>> Nobody loses.
>
> Except those of us that don't want to needlessly have to track two 
> codebases for no reason. :) By following your logic here, it wouldn't 
> take much for us to suddenly have five or six different "wrapper" 
> packages to "try out ideas".

But it's a *wrapper*, not a fork.  A wrapper isn't a codebase to track 
really -- except to the degree that it might use some private 
interfaces or otherwise be sensitive to changes in the wrapped package. 
  But that just means the wrapper is tied to a version, or the author 
has to keep track of changes; it's not that big a deal.

The wrapper is Good Enough for David.  If there are features that other 
people really like in it, then certainly they can be moved to the main 
SQLObject code (as long as those other people speak up).  Really, time 
will tell.

>>> [number of columns perhaps?], but len() on a SelectResults is 
>>> already done by using the count() method on an instance.)
>>
>> len(something) is slightly more readable and convenient.
>
> As Ian mentioned, that was specifically removed from SQLObject a 
> little while back.

Right, but he wouldn't know that.  Anyway, I added this as a FAQ since 
it's actually come up a couple times since I made the change.

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