Phillip J. Eby wrote: > At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote: >>On 3/28/06, Anthony Baxter <anthony at interlink.com.au> 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 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? > > Pro: > > * SQLite is really nice to have for writing simple applications with small > data needs, especially client-side software. It's probably the > best-of-breed open source embedded SQL DB right now. > > * So, having a wrapper would be a big "Batteries included" plus for Python > > Con: > > * Competing Python wrappers exist Which aren't DBAPI compliant, and I think not nearly as popular. > * SQLite itself is updated frequently, let alone the wrappers That's a point. > * Build integration risks unknown, possible delay of 2.5? There could be an sqlite-integration branch. If it's ready for beta 1, it is merged then, if not, it is merged to trunk after 2.5 final happened. Georg
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4