Carsten Haese wrote:
> On Wed, 20 Jun 2007 22:59:18 -0500, Carl Karsten wrote
>> "super simple" would be the new api. pretty easy is the wrapper
>> for backwards computability.
>>
>> As complex as that set would be, it wouldn't be much worse than the
>> current mess.
>
> That's why we're discu
On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > The advantages are clear:
> >
> > * Application code written against this spec can be sure that named/qmark
> > styles are available, and there is a common API for choosing which one to
> > use.
> > That means less
Carsten Haese wrote:
> On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
>> Carsten Haese wrote:
>>> The advantages are clear:
>>>
>>> * Application code written against this spec can be sure that named/qmark
>>> styles are available, and there is a common API for choosing which one to
>>> us
When we talk about backwards compatibility, I am wondering exactly what that
means.
I think my question is: should code that does not follow the dbapi2 spec be
guaranteed to work?
For instance, I know some of the dbapiv2 modules support more than one
paramstyle, yet the spec really only allows
On Thu, 2007-06-21 at 09:14 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 07:31 -0500, Carl Karsten wrote:
> >> Carsten Haese wrote:
> >>> The advantages are clear:
> >>>
> >>> * Application code written against this spec can be sure that named/qmark
> >>> styles are a
[Please calm down a bit.]
On 2007-06-21 16:14, Carl Karsten wrote:
> Carsten Haese wrote:
* APIs aren't forced to abandon "legacy" parameter styles so existing code
written for existing APIs won't break.
* No backwards compatibility wrapper is necessary.
>>> I do not see t
On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
> When we talk about backwards compatibility, I am wondering exactly what that
> means.
A module is backwards compatible if code using it won't break if the
module is replaced with a newer version.
> I think my question is: should code that
I've been reading the arguments going back and forth over parameter
styles and I have a different suggestion which might help us out of
this morass -- or perhaps provide additional fodder for the flame war
that appears to be starting -)
Define the method for cursor.execute() as follows:
def e
I have been recently playing with context managers and the new "with"
statement added in Python 2.5. I would like to suggest the addition of
the following methods to connections:
def __enter__(self):
return self
def __exit__(self, excType, excValue, excTraceback):
if excType is None and
Carsten Haese wrote:
> On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
>> When we talk about backwards compatibility, I am wondering exactly what that
>> means.
>
> A module is backwards compatible if code using it won't break if the
> module is replaced with a newer version.
Even if it r
Anthony Tuininga wrote:
> I have been recently playing with context managers and the new "with"
> statement added in Python 2.5. I would like to suggest the addition of
> the following methods to connections:
>
> def __enter__(self):
> return self
>
> def __exit__(self, excType, excValue, ex
On 2007-06-21 18:41, Anthony Tuininga wrote:
> I have been recently playing with context managers and the new "with"
> statement added in Python 2.5. I would like to suggest the addition of
> the following methods to connections:
>
> def __enter__(self):
> return self
>
> def __exit__(self,
On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
> >> When we talk about backwards compatibility, I am wondering exactly what
> >> that means.
> >
> > A module is backwards compatible if code using it won't br
On Thu, 2007-06-21 at 10:41 -0600, Anthony Tuininga wrote:
> I have been recently playing with context managers and the new "with"
> statement added in Python 2.5. I would like to suggest the addition of
> the following methods to connections:
>
> def __enter__(self):
> return self
>
> def _
Carsten Haese wrote:
> On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote:
>> Carsten Haese wrote:
>>> On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
When we talk about backwards compatibility, I am wondering exactly what
that means.
>>> A module is backwards compatible if cod
On Thu, 2007-06-21 at 14:30 -0500, Carl Karsten wrote:
> Carsten Haese wrote:
> > On Thu, 2007-06-21 at 11:51 -0500, Carl Karsten wrote:
> >> Carsten Haese wrote:
> >>> On Thu, 2007-06-21 at 10:02 -0500, Carl Karsten wrote:
> When we talk about backwards compatibility, I am wondering exact
I like the idea of using *args and **kwargs a lot. Not having to
build a sequence is nice and is an option I already provide in pyodbc:
cursor.execute("insert into t(?,?)", a, b)
Using the two items to differentiate between qmark and named seems
like a simple idea and does not require connecti
I'm not sure if there is a need for context support at the moment.
Almost all databases automatically rollback transactions if they are
not committed before a connection is closed. In the pyodbc connection
finalizer, I automatically issue a rollback if a commit didn't occur.
Since CPython uses re
On 6/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 10:41 -0600, Anthony Tuininga wrote:
> > I have been recently playing with context managers and the new "with"
> > statement added in Python 2.5. I would like to suggest the addition of
> > the following methods to connec
Carl Karsten schrieb:
> >>> numeric -1
> >>> format -5
> >>> pyformat -2
>
> To me that reads "remove them." 0 would have been "tolerate them."
It seems the "format" and "pyformat" syntax will be abandoned in Python
3.0 anyway (in favor of yet another syntax) so that would be another
rea
On Thu, 2007-06-21 at 14:26 -0600, Anthony Tuininga wrote:
> On 6/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> > with api.connect(dbname) as conn:
> >with conn.cursor() as cur:
> > cur.execute(stmt)
>
> That's interesting but is it of much use? Connections and cursors
> close themse
On 6/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> On Thu, 2007-06-21 at 14:26 -0600, Anthony Tuininga wrote:
> > On 6/21/07, Carsten Haese <[EMAIL PROTECTED]> wrote:
> > > with api.connect(dbname) as conn:
> > >with conn.cursor() as cur:
> > > cur.execute(stmt)
> >
> > That's interes
Carl Karsten wrote at 2007-6-21 07:31 -0500:
> ...
>I did before: "only allow one style of parameter." But it got out voted, (or
>not even on the ballot) and so I won't push for it anymore.
>
> >>> numeric -1
> >>> format -5
> >>> pyformat -2
>
>To me that reads "remove them." 0 would have be
On Thu, 2007-06-21 at 16:39 -0600, Anthony Tuininga wrote:
> I have not released this publicly yet, no. It would be a good idea to
> have agreement on this rather than have conflicting implementations.
Indeed. I see two alternatives, modulo naming:
1) A connection method:
with conn.transaction()
24 matches
Mail list logo
