Jason Stitt wrote: > On Oct 19, 2005, at 9:18 PM, [EMAIL PROTECTED] wrote: > > <snip> > >>My solution is sqlstring. A single-purpose library: to create SQL >>statement objects. These objects (such as sqlstring.Select), represent >>complex SQL Statements, but as Python objects. > > > <snip> > > First of all, I like this idea. I've been thinking about doing > something similar but am stuck with SQLObject for the moment. The > ability to construct complex expressions in pieces and then mix and > match them would be killer. > > I think some operator overloading, especially the obvious cases like > ==, is cleaner than using only functions because it lets you order > things normally. But some of the operator choices are non-intuitive. > Personally, I would make something like 'alias' a function or class, > rather than overloading XOR. Not sure about ** for where. > > Using // for 'in' looks really weird, too. It's too bad you can't > overload Python's 'in' operator. (Can you? It seems to be hard-coded > to iterate through an iterable and look for the value, rather than > calling a private method like some other builtins do.) > >>> class inplus(object): ... def __contains__(self, thing): ... print "Do I have a", thing, "?" ... return True ... >>> x = inplus() >>> "Steev" in x Do I have a Steev ? True >>> [...]
regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ -- http://mail.python.org/mailman/listinfo/python-list
