Title: RE: sqlstring -- a library to build a SELECT statement
Tim Roberts wrote:
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> >
> >An Example:
> >
> >>>> import sqlstring
> >>>> model = sqlstring.TableFactory()
> >&
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
>An Example:
>
import sqlstring
model = sqlstring.TableFactory()
print model.person
>SELECT
>person.*
>FROM
>[person] person
The [bracket] syntax is unique to Microsoft. Everyone else, including
Microsoft SQL Server, uses "double quo
> person ** (
> (person.type_id == 'customer')
> & (person.id %= phone(phone.person_id)))
> )
>
Nevermind. This doesn't work because all of the X= operators in
question are assignment operators, and therefore generate a Syntax
Error if in a nested expression. I think I've settled on just doin
Tom Anderson wrote:
> On Thu, 20 Oct 2005, [EMAIL PROTECTED] wrote:
>
> > On this line of thought, what about the += operator? That might be more
> > intuative than //. I could even use -= for not in.
>
> You're going to have to explain to me how using an assignment operator for
> something othe
On Thu, 20 Oct 2005, Pierre Quentel wrote:
[EMAIL PROTECTED] a écrit :
My solution is sqlstring. A single-purpose library: to create SQL
statement objects.
With the same starting point - I don't like writing SQL strings inside Python
code either - I have tested a different approach : use th
On Thu, 20 Oct 2005, [EMAIL PROTECTED] wrote:
> On this line of thought, what about the += operator? That might be more
> intuative than //. I could even use -= for not in.
You're going to have to explain to me how using an assignment operator for
something other than assignment is intuitive!
[EMAIL PROTECTED] a écrit :
>
>
> 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. The benefit is that you
> can, at run-time, "build" the statement pythonica
> >> 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.)
> >>
> >
> > // was a
> The big operator question will be: how will "and" and "or" be
> implemented? This is always a sticking point because of Python's
> short-circuiting behaviors regarding them (the resultant bytecode will
> include a JUMP).
I'm using the Boolean | and & operators for logical groups, eg (a | b |
(b
On Oct 19, 2005, at 11:55 PM, [EMAIL PROTECTED] wrote:
>
> Jason Stitt wrote:
>
>>
>> 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
>> c
On Oct 20, 2005, at 2:19 AM, Steve Holden wrote:
> Jason Stitt wrote:
>> 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 pri
Jason Stitt wrote:
> On Oct 19, 2005, at 9:18 PM, [EMAIL PROTECTED] wrote:
>
>
>
>>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.
>
>
>
>
> First of al
[EMAIL PROTECTED] wrote:
> These objects (such as sqlstring.Select), represent
> complex SQL Statements, but as Python objects. The benefit is that you
> can, at run-time, "build" the statement pythonically, without
> getting bogged down in String Manipulation. The theory is that once in
> use, thi
[EMAIL PROTECTED] wrote:
> Jason Stitt wrote:
>
>>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
Jason Stitt wrote:
>
> 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 cl
On Oct 19, 2005, at 9:18 PM, [EMAIL PROTECTED] wrote:
> 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.
First of all, I like this idea. I've been thinkin
After some thought on what I need in a Python ORM (multiple primary
keys, complex joins, case statements etc.), and after having built
these libraries for other un-named languages, I decided to start at the
bottom. What seems to plague many ORM systems is the syntactic
confusion and string-manipula
17 matches
Mail list logo
