Martin v. Löwis wrote:
Terry Reedy wrote:
Gerhard Häring [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I proposed to link dynamically on Windows, and ship the Windows
SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in
Fredrik Lundh wrote:
Greg Ewing wrote:
Firebird could be a solution to this.
so a library that doesn't support multiple independent
readers/writers on a single file at all is much better
than one that does,
Where do you get that from? Firebird supports
multiple readers/writers
Greg Ewing wrote:
Firebird could be a solution to this.
so a library that doesn't support multiple independent
readers/writers on a single file at all is much better
than one that does,
Where do you get that from? Firebird supports
multiple readers/writers perfectly well.
not
On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote:
-1 on db.sql.sqlite.
Keep structure flat. Or we are eventually in a Java world with
org.something.this.andthat
xml.dom.minidom?
--
http://www.lexical.org.uk/ | http://covertmusic.com/ | work: [EMAIL PROTECTED]
On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that
you are talking about adding a *very* popular module name to
the top-level Python namespace if you go for db or database.
Why can't we just have the pysqlite package as top-level
On Thursday 30 March 2006 22:25, Andrew Walkingshaw wrote:
On Wed, Mar 29, 2006 at 05:24:32PM +0200, Wolfgang Langner wrote:
-1 on db.sql.sqlite.
Keep structure flat. Or we are eventually in a Java world with
org.something.this.andthat
xml.dom.minidom?
given the horror of
Anthony Baxter wrote:
xml.dom.minidom?
given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to
use the xml package as an example of _anything_ wink
which reminds me -- is that issue still open ? martin? fred?
/F
___
Python-Dev
Anthony Baxter wrote:
On Thursday 30 March 2006 22:31, M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that
you are talking about adding a *very* popular module name to
the top-level Python namespace if you go for db or database.
Why can't we just have the
M.-A. Lemburg wrote:
[...]
Also your statement regarding sqlite3 suggests that sqlite
itself is not included - why not ?
- SQLite sources are 1.57 MiB uncompressed, we wouldn't want to add that
to the Python sources download size, would we?
- I personally would not want to have the job to
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite',
instead.
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
I can't think of a better name right now - can anyone else, or should
it
Anthony Baxter wrote:
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that sqlite was the name used by the first pysqlite
generation:
$ python2.3
import sqlite
sqlite.version
'1.1.6'
I'm not sure how much
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite',
instead.
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
I can't think of a better name right now - can
Fredrik Lundh wrote:
Anthony Baxter wrote:
Such a module name is less likely to cause problems.
Excellent point. Hm. Maybe we should just go with 'sqlite', instead.
except that sqlite was the name used by the first pysqlite
generation:
$ python2.3
import sqlite
sqlite.version
M.-A. Lemburg wrote:
Will it also work with e.g. sqlite 2.8.15 (ie. sqlite v3) -
this is the standard version on SuSE 9.2.
No, SQLite 3 has a completely different API than SQLite 2.x. If you need
a Python module for it, you can use pysqlite 1.0.1.
Also your statement regarding sqlite3
Fredrik Lundh wrote:
xml.dom.minidom?
given the horror of _xmlplus/xmlcore and whatnot, I'd be hesitant to
use the xml package as an example of _anything_ wink
which reminds me -- is that issue still open ? martin? fred?
It still is. I wonder whether I should just revert the change.
M.-A. Lemburg wrote:
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite',
instead.
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
I can't think of a better
Anthony Baxter wrote:
On Friday 31 March 2006 02:04, M.-A. Lemburg wrote:
Excellent point. Hm. Maybe we should just go with 'sqlite',
instead.
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
I can't think of a better name right now - can
I think sqlite is just fine.
I do, too.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
So do I.
On 3/30/06, Bill Janssen [EMAIL PROTECTED] wrote:
I think sqlite is just fine.
I do, too.
Bill
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
Anthony Baxter [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Anything, but please no db or database top-level module or
package :-)
How about sql? wink
Whereas I am quite happy with a 'db' package, and would like to see other
db stuff put under it.
tjr
Gerhard Häring [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I proposed to link dynamically on Windows, and ship the Windows
SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in
case of emergency
+1 and thanks from a
Fredrik Lundh wrote:
not according to the documentation (which says that the embedded library locks
the database file, to prevent other independent processes from accessing the
data).
I think that means other *non-Firebird* processes.
Firebird itself uses a system of file locks and
M.-A. Lemburg wrote:
I don't really care about the name, but please be aware that
you are talking about adding a *very* popular module name to
the top-level Python namespace if you go for db or database.
This would only be an issue for an application that
had a private module calle db, since
Terry Reedy wrote:
Gerhard Häring [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
I proposed to link dynamically on Windows, and ship the Windows
SQLite3.DLL. This has two advantages:
- Python users can upgrade the SQLite3.DLL by a simple download from in
case of emergency
+1
On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the
On Wednesday 29 March 2006 06:33, Georg Brandl wrote:
Fredrik Lundh wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules
was planned.
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for
Neal Norwitz wrote:
On 3/28/06, Gerhard Häring [EMAIL PROTECTED] wrote:
Even better, the authors should be willing to keep the version in
Python synchronized with the separate release.
In particular, I would then synchronize changes that have proven stable
in the standalone release to the
Anthony Baxter wrote:
db.sqlite3 ?
That would make sense if inclusion of more database-related modules
was planned.
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package
On Wed, 2006-03-29 at 09:35 +0200, Gerhard Häring wrote:
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite module. I think this
is how Barry does it with the email module, too.
I do things a little differently, at
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package importing works. And I'd prefer
'database.sqlite' rather than
Barry Warsaw wrote:
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package importing works. And I'd prefer
'database.sqlite'
Gerhard Häring writes:
db.sql.sqlite is another possibility, if adding something like Durus or
ZODB in the same top-level namespace could be considered for 2.6.
Flat is better than nested. I see no reason why we couldn't have all of
this:
database.sqllite
database.zodb
database.duras
On Wed, Mar 29, 2006 at 07:22:01AM -0800, Michael Chermside wrote:
Flat is better than nested. I see no reason why we couldn't have all of
this:
database.sqllite
database.zodb
database.duras
database.oracle
there's no need to group the SQL databases.
If flat is really so
On Wed, Mar 29, 2006, Fredrik Lundh wrote:
Anthony Baxter wrote:
And I'd prefer 'database.sqlite' rather than 'db.sqlite'.
and extensible_markup_language.document_object_model over
xml.dom, I presume ? ;-)
While I see your point, from my POV xml feels different from db.
Part of it is
At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too.
FYI, there's a reST-PythonDoc converter somebody wrote:
http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
I'm planning to try it for porting the setuptools docs. I'm sure that
editing
I think short names are more more consistent with the existing naming in
the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level
package names as aliases for existing shorter top-level package names.
Bill
___
Bill Janssen wrote:
I think short names are more more consistent with the existing naming in
the standard library.
Which doesn't make it a good idea. +1 on adding longer top-level
package names as aliases for existing shorter top-level package names.
Which existing short names do you have
Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too. What I'd personally
like to offload are these two tasks:
- integreting pysqlite into the Python build process
- in particular the win32 build process
I would have access to Linux and win32 development machines with
Gerhard Häring wrote:
In particular, I would then synchronize changes that have proven stable
in the standalone release to the Python core sqlite module. I think this
is how Barry does it with the email module, too.
Sounds all fine to me.
Regards,
Martin
On 3/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no, but only because things like ElementTree didn't,
either. Does it need a BDFL pronouncement? I'd say yes.
Unless you've recanted on that already, let me point
At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
On 3/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no, but only because things like ElementTree didn't,
either. Does it need a BDFL pronouncement? I'd say
Phillip J. Eby wrote:
At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
On 3/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no, but only because things like ElementTree didn't,
either. Does it need a BDFL
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've
never seen sqlite, and I've ignored this thread, so I don't know what
the disagreement is all about. Perhaps one person in favor and one
person against could summarize the argument for me? Otherwise I'll
Martin v. Löwis wrote:
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've
never seen sqlite, and I've ignored this thread, so I don't
know what
the disagreement is all about. Perhaps one person in favor and one
person against could summarize the
Robert Brewer wrote:
More Against?:
Explaining database is locked errors (due to SQLite's exposed
multiple-readers/one-writer design) on a daily basis (FAQ entries
notwithstanding).
wow. that's one quality argument. what's wrong with you ?
/F
Guido van Rossum wrote:
Unless you've recanted on that already, let me point out that I've
never seen sqlite, and I've ignored this thread, so I don't know what
the disagreement is all about.
what disagreement ?
sqlite is a widely used light-weight SQL library (http://www.sqlite.org)
that's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Phillip J. Eby wrote:
At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
[...] Perhaps one person in favor and one
person against could summarize the argument for me?
Pro:
* SQLite is really nice to have for writing simple applications with
gerald's pysqlite binding
sorry, gerhard.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 3/29/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Pro: [...]Con:* Competing Python wrappers exist
* SQLite itself is updated frequently, let alone the wrappers* Build integration risks unknown, possible delay of 2.5?* Another external library to track and maybe have emergency updates ofAll of
Phillip Pro:
Phillip * SQLite is really nice to have for writing simple applications
Phillip with small data needs, especially client-side software. It's
Phillip probably the best-of-breed open source embedded SQL DB right
Phillip now.
Phillip * So, having a wrapper
[EMAIL PROTECTED] wrote:
I haven't been tracking the pysqlite discussion either, but one con you
missed is that regardless of pro #1 people will almost certainly apply it to
problems for which it is ill-suited, reflectly poorly on both Python and
SQLite.
the arguments keep getting more and
from a user perspective, adding this to the standard library is a no-brainer.
the only reason not to add it would be if the release managers don't have
time to sort out the build issues.
I agree with Fredrik here.
On the package naming issue: using em for email would be wrong,
just as db for
On Wednesday 29 March 2006 08:22, Jean-Paul Calderone wrote:
Agreed. pysqlite is solid and widely accepted, and AFAIK has no
competition.
FWIW: http://www.rogerbinns.com/apsw.html
Looks interesting, but not being DB-API compliant is a huge issue for
the stdlib. Part of the reason I want to
At 04:00 PM 3/29/2006 -0600, [EMAIL PROTECTED] wrote:
Is it not possible to distribute an empty db package which is then populated
with various database eggs (or other similar installation things)?
I don't think I understand your question.
If you are asking whether it's possible to have
Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of the way package importing works. And I'd prefer
'database.sqlite' rather than 'db.sqlite'.
Perhaps dbapi2.sqlite?
Tim
On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
from a user perspective, adding this to the standard library is a
no-brainer. the only reason not to add it would be if the release
managers don't have time to sort out the build issues.
Ok - well, I'm willing to work with Gerhard to do
Bill Janssen wrote:
On the package naming issue: using em for email would be wrong,
just as db for database would be wrong.
are you aware of the fact that the module implements the db-api ?
/F
___
Python-Dev mailing list
Python-Dev@python.org
Bill Janssen [EMAIL PROTECTED] wrote:
On the package naming issue: using em for email would be wrong,
Eh, that should be import electronic_mail, then. And
import simple_mail_transport_protocol_lib.
just as db for database would be wrong.
People who are familiar with Extensible Markup
On 3/29/06, Anthony Baxter [EMAIL PROTECTED] wrote:
On Thursday 30 March 2006 08:15, Fredrik Lundh wrote:
from a user perspective, adding this to the standard library is a
no-brainer. the only reason not to add it would be if the release
managers don't have time to sort out the build
Fredrik writes:
are you aware of the fact that the module implements the db-api ?
db-api is just an earlier version of the same naming mistake. I'd
be happy with database_api instead of database.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
Charles Cabazon writes:
On the package naming issue: using em for email would be wrong,
Eh, that should be import electronic_mail, then. And
import simple_mail_transport_protocol_lib.
just as db for database would be wrong.
People who are familiar with Extensible Markup Language
Charles Cabazon writes:
Whoops! Should be Cazabon.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
I haven't been tracking the pysqlite discussion either, but one con
you missed is that regardless of pro #1 people will almost certainly
apply it to problems for which it is ill-suited, reflectly poorly on
both Python and SQLite.
Fredrik the arguments keep getting more
Is it not possible to distribute an empty db package which is then
populated with various database eggs (or other similar installation
things)?
Phillip I don't think I understand your question.
Someone was throwing around names like db.sqlite as the place to install
pysqlite.
Anthony All naming in the stdlib is adhoc by it's nature. We choose a
Anthony name, and then that's it's name. I'm pretty happy with either
Anthony 'db.sqlite' or 'database.sqlite', really.
Let's slow down here. If we are really going to start putting together a
package
Bill Janssen wrote:
db and em are too short to be useful context-free abbreviations,
There's a big difference between db and em: db is
an extremely well-known abbreviation, whereas em isn't.
At the top level of a reorganised package namespace, I
don't think it would be out of place to reserve
Greg There's a big difference between db and em: db is an
Greg extremely well-known abbreviation, whereas em isn't.
Unless you're a typesetter or a TeX hound... :-)
Skip
___
Python-Dev mailing list
Python-Dev@python.org
[EMAIL PROTECTED] wrote:
The powers-that-be didn't want to support
another database server (we already have Sybase) and didn't want our group's
experimental data polluting the production database, so the folks who
wanted it went the SQLite/pysqlite route. They were immediately bitten by
the
[EMAIL PROTECTED] wrote:
If I want to install Object Craft's Sybase wrapper the
logical place for it seems like stdlib.db.sybase. But that's not right
because the Sybase module's not part of the stdlib. Okay, it belongs in
site.db.sybase. But now we have two different db packages and the
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
While we're at it, we could spell import select. :-)
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
On Thursday 30 March 2006 12:07, [EMAIL PROTECTED] wrote:
To many people SQL in the name implies big databases. I know
from personal experience at work. The powers-that-be didn't want
to support another database server (we already have Sybase) and
didn't want our group's experimental data
On Thursday 30 March 2006 12:15, [EMAIL PROTECTED] wrote:
Someone was throwing around names like db.sqlite as the place to
install pysqlite.
Dunno who originally suggested it, but the theory was that there's
some issue with toplevel library namespace pollution. I'm not too
stressed out one
[EMAIL PROTECTED] wrote:
Greg There's a big difference between db and em: db is an
Greg extremely well-known abbreviation, whereas em isn't.
Unless you're a typesetter or a TeX hound... :-)
Good point! Still, the fact remains that it's
not a well-known abbreviation for *email*. :-)
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
While we're at it, we could spell import select. :-)
Getting off on a tangent here, but I would actually
like
Hello,
I think short names are more more consistent with the existing naming in
the standard library.
+1 on db.sqlite from me.
same for me +1 on db.sqlite
db.sql.sqlite is another possibility, if adding something like Durus or
ZODB in the same top-level namespace could be considered for
At 03:21 PM 3/30/2006 +1200, Greg Ewing wrote:
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
While we're at it, we could spell import select. :-)
Getting
On Wed, Mar 29, 2006 at 03:35:48PM +0200, Gerhard H?ring wrote:
Barry Warsaw wrote:
On Wed, 2006-03-29 at 19:47 +1100, Anthony Baxter wrote:
My only concern about this is that it wouldn't be possible for other
authors to provide 3rd party packages as (for instance) db.mysqldb
because of
Greg Ewing wrote:
Firebird could be a solution to this. It can be
used in a mode that doesn't need a server, and it
has no trouble at all with concurrency or large
amounts of data that I know of.
so a library that doesn't support multiple independent readers/writers on
a single file at all
On Wed, Mar 29, 2006 at 11:47:10PM +0200, Thomas Wouters wrote:
Con:
* Competing Python wrappers exist
* SQLite itself is updated frequently, let alone the wrappers
* Build integration risks unknown, possible delay of 2.5?
* Another external library to track and maybe have emergency
Gerhard Häring wrote:
Georg Brandl wrote:
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere
since, AFAICR. Do we want to consider including pysqlite in Python
2.5? It's the only DB adaptor that I'd really consider suitable for
shipping with the
Georg Brandl wrote:
Gerhard Häring wrote:
I'll try to throw in a bit more information that will be necessary for
this discussion:
pysqlite 2.x is (almost) feature complete now. I've a few more changes
sitting in SVN trunk that are waiting for the pysqlite 2.2 release.
These are all about
On Tue, 2006-03-28 at 17:59 +1100, Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere
since, AFAICR. Do we want to consider including pysqlite in Python
2.5? It's the only DB adaptor that I'd really consider suitable for
shipping with the distribution,
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no, but only because things like ElementTree didn't,
either. Does it need a BDFL pronouncement? I'd say yes.
Anthony
___
Python-Dev mailing list
Python-Dev@python.org
Gerhard Häring wrote:
I know that pushing new things into Python 2.5 should happen soon, if at
all. So *if* pysqlite should go into Python, I propose that I release
pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
If this is going to happen, I want it to happen under
Anthony Baxter wrote:
This came up before (back in October 2004!) but didn't go anywhere
since, AFAICR. Do we want to consider including pysqlite in Python
2.5? It's the only DB adaptor that I'd really consider suitable for
shipping with the distribution, because it's self-contained.
Fredrik Lundh wrote:
Gerhard Häring wrote:
I know that pushing new things into Python 2.5 should happen soon, if at
all. So *if* pysqlite should go into Python, I propose that I release
pysqlite 2.2.0 and we integrate that into the Python alpha release.
+1 !
If this is going to happen,
Georg Brandl [EMAIL PROTECTED] wrote:
Fredrik Lundh wrote:
db.sqlite3 ?
+1
That would make sense if inclusion of more database-related modules was
planned.
Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as
appropriate, and having a nice new namespace ready for them is a
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no,
Agreed. pysqlite is solid and widely accepted, and AFAIK has no
competition.
but only because things like ElementTree didn't,
either. Does it need
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no,
Agreed. pysqlite is solid and widely accepted, and AFAIK has no
competition.
At 04:22 PM 3/28/2006 -0500, Jean-Paul Calderone wrote:
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no,
Agreed. pysqlite
On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote:
On the plus side, it sounds like ASPW is a more general wrapping of SQLite,
which seems to me to lean in its favor for the stdlib, if it can also be
brought into DBAPI compliance.
If there's some general uncertainty about which to
Yup; I'd be happy to see db.mysql and db.pgsql or whatnot added as
appropriate, and having a nice new namespace ready for them is a good idea.
I really wish that that namespace would be database, not db.
Bill
___
Python-Dev mailing list
Barry Warsaw [EMAIL PROTECTED] wrote:
On Tue, 2006-03-28 at 18:24 -0500, Phillip J. Eby wrote:
On the plus side, it sounds like ASPW is a more general wrapping of SQLite,
which seems to me to lean in its favor for the stdlib, if it can also be
brought into DBAPI compliance.
If
94 matches
Mail list logo
