[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 quotes to protect special
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()
print model.person
SELECT
person.*
FROM
[person] person
The [bracket] syntax is unique to
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 private
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
calling 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 c)).
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 bit of a stretch.
[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 pythonically,
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!
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
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 other than
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 doing a
[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, things
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
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
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
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 class,
[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 builtins
17 matches
Mail list logo
