Ian Bicking wrote:
> Carsten Haese wrote:
>> I agree that if we decide to abolish (py)format, we should help out
>> module authors for databases that don't natively support '?' by
>> providing example code for performing the necessary parsing.
>
> When using a higher-level SQL generator the parsin
Hi guys.
So, I've been meaning to bring this up here, and what with the param
marker discussions...
Anyway, while doing the SQLObject 2 rewrite I wanted to extract some of
the machinery that has nothing to do with ORM stuff. The result is
SQL-API: http://sqlobject.org/sqlapi/
Instead of fixi
On Wed, 2006-04-19 at 09:56 -0500, Lukasz Szybalski wrote:
> Hello again,
> Not sure if this is a right place to ask this but is there a "fox pro"
> substitute in Linux or a program that would act in a similar way but
> be platform independent (Linux,mac,win)?
>
> Fox pro aka, GUI way to design la
On Wednesday 19 April 2006 16:56, Lukasz Szybalski wrote:
>Hello again,
>Not sure if this is a right place to ask this but is there a "fox pro"
>substitute in Linux or a program that would act in a similar way but
>be platform independent (Linux,mac,win)?
>
>Fox pro aka, GUI way to design layout fo
Carsten Haese wrote:
> On Wed, 2006-04-19 at 11:38, Gerhard Häring wrote:
>
>>Abolishing (py)format certainly means additional work for the module
>>authors. If we do so - I haven't read the whole thread, so I don't know
>>what the arguments are for it - then we should include example code in
>
On Wed, 2006-04-19 at 11:38, Gerhard Häring wrote:
> Abolishing (py)format certainly means additional work for the module
> authors. If we do so - I haven't read the whole thread, so I don't know
> what the arguments are for it - then we should include example code in
> the DB-API for parsing qm
M.-A. Lemburg wrote:
> [...]
> If that's the case, then I suppose supporting qmark style
> wouldn't be too much of a problem.
It's doable, but it requires parsing the SQL, i. e. find all the qmarks
that are not inside SQL string literals.
Databases like MySQL, PostgreSQL (*) and SQLite 2.x don't
M.-A. Lemburg wrote:
>>The ones I know about (pysqlite 1.x, pyPgSQL, psycopg, MySQLdb) all only
>>look at the Python values, not at the pyformat format character for
>>deciding how to bind the variable.
>
>
> If that's the case, then I suppose supporting qmark style
> wouldn't be too much of a
Lukasz Szybalski wrote:
> Hello again,
> Not sure if this is a right place to ask this but is there a "fox pro"
> substitute in Linux or a program that would act in a similar way but
> be platform independent (Linux,mac,win)?
>
> Fox pro aka, GUI way to design layout for database results, drug and
Check out Dabo :)
http://dabodev.com/
--PLB
At 16:56 19.4.06, Lukasz Szybalski wrote:
>Hello again,
>Not sure if this is a right place to ask this but is there a "fox pro"
>substitute in Linux or a program that would act in a similar way but
>be platform independent (Linux,mac,win)?
>
>Fox pro
Carsten Haese wrote:
> On Wed, 2006-04-19 at 10:20, M.-A. Lemburg wrote:
>> Carsten Haese wrote:
>>> On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
I've found the qmark style to be sufficient for everything
>>> I agree. Considering that many modules already support qmark, and those
>>> that
Gerhard Häring wrote:
> M.-A. Lemburg wrote:
>> Carsten Haese wrote:
>>
>>> On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
>>>
I've found the qmark style to be sufficient for everything
>>> I agree. Considering that many modules already support qmark, and those
>>> that currently use 'forma
Hello again,
Not sure if this is a right place to ask this but is there a "fox pro"
substitute in Linux or a program that would act in a similar way but
be platform independent (Linux,mac,win)?
Fox pro aka, GUI way to design layout for database results, drug and
drop, adjust size by mouse, create
On Wed, 2006-04-19 at 10:20, M.-A. Lemburg wrote:
> Carsten Haese wrote:
> > On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
> >> I've found the qmark style to be sufficient for everything
> >
> > I agree. Considering that many modules already support qmark, and those
> > that currently use 'for
>On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
>> I've found the qmark style to be sufficient for everything
This is more about convenience (same as Python positional arguments vs.
keyword arguments). Celko's book on SQL tree structures is full of
examples using :names, with the same name appe
M.-A. Lemburg wrote:
> Carsten Haese wrote:
>
>>On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
>>
>>>I've found the qmark style to be sufficient for everything
>>
>>I agree. Considering that many modules already support qmark, and those
>>that currently use 'format'/'pyformat' would have to mov
On 4/19/06, Andy Todd <[EMAIL PROTECTED]> wrote:
> Lukasz Szybalski wrote:
> > On 4/18/06, Lukasz Szybalski <[EMAIL PROTECTED]> wrote:
> >> On 4/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> >>> On Mon, 17 Apr 2006, Andy Todd wrote:
> >>>
> > stmt = "INSERT INTO table_x (body) VALUE
Carsten Haese wrote:
> On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
>> I've found the qmark style to be sufficient for everything
>
> I agree. Considering that many modules already support qmark, and those
> that currently use 'format'/'pyformat' would have to move to something
> else if thes
On Wed, 2006-04-19 at 08:24, M.-A. Lemburg wrote:
> I've found the qmark style to be sufficient for everything
I agree. Considering that many modules already support qmark, and those
that currently use 'format'/'pyformat' would have to move to something
else if these are dropped, I'd like to sugge
Andy Todd wrote:
> Once more, %s is simply a marker in the statement you provide to the
> execute method which says "substitute the next item from the tuple I've
> provided here please". It is not string substitution.
>
> Now hands up for changing the DB-API to remove the pyformat paramstyle?
>
On Wed, 2006-04-19 at 03:45, Andy Todd wrote:
> Now hands up for changing the DB-API to remove the pyformat paramstyle?
> If we're going to have options I think we should restrict them to either
> named parameters (a la cx_Oracle) or the '?' qmark (a la ODBC and JDBC).
I'm all for that with the
Lukasz Szybalski wrote:
> On 4/18/06, Lukasz Szybalski <[EMAIL PROTECTED]> wrote:
>> On 4/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>> On Mon, 17 Apr 2006, Andy Todd wrote:
>>>
> stmt = "INSERT INTO table_x (body) VALUES (%s)" # [1]
> cursor.execute(stmt, (body,))
>>
22 matches
Mail list logo
