|
From: Andrew B. <an...@ca...> - 2005-07-15 03:36:50
|
On Thu, Jul 14, 2005 at 06:40:52PM -0700, da...@eg... wrote:
> On Jul 14, 2005, at 5:54 PM, Andrew Bennetts wrote:
> >On Thu, Jul 14, 2005 at 04:28:19PM -0700, da...@eg... wrote:
> >I don't think this is a serious problem with selectBy. It's unlikely
> >that column names will clash with those keyword arguments. If it is a
> >problem, we could use a convention like treating "orderBy_" as meaning a
> >column named "orderBy" -- I think I've seen that used in e.g. Nevow's
> >"stan" API, to workaround the problem of "class" being a reserved word in
> >Python but also a common attribute in HTML.
>
> For me the question of column names clashing
> with the keywords is less of the issue than the
> simple fact of using kwargs for two different
> purposes. I also implemented what you have,
> but ended up looking at code like:
>
> r = t.selectBy(col=val,
> orderBy=ordercol,
> this=that,
> connection=c,
> )
[...]
Oh, I see. I understand your point now. Thanks for the clarification!
I guess selectBy could be superseded by select with a "byCols" helper, that
would look like:
r = t.select(byCols(col=val), orderBy=ordercol, etc=etc)
But it feels a bit ugly to me. I guess the byCols helper would be part of
SQLBuilder.
[...]
> >I share your concerns about "there should be only one way to do it", but
> >in this case I think practicality beats purity.
>
> I think you may be right for the selectOne() problem
> (although I do wish someone would come up with
> an elegant solution!).
Me too! I'd love to see an idea that makes everyone instantly happy here,
but until then I'll keep advocating for selectOne.
Thanks for your thoughts!
-Andrew.
|
