Re: [Python-Dev] pysqlite for 2.5?
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 case of emergency +1 and thanks from a Windows user This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)? AFAIK SQLite does not use stdio or locales. Memory management is normally never done explicitly, but by API calls using opaque pointers to the SQLite structure, for example: - sqlite3_compile will return a SQLite statement. - sqlite3_finalize will clean up the SQLite statement, and return any memory used by it. The only explicit memory management function I know is void sqlite3_free(char *z); which looks ok, too. And pysqlite doesn't use it, anyway. -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 perfectly well. Greg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 according to the documentation (which says that the embedded library locks the database file, to prevent other independent processes from accessing the data). but that might of course be misleading or outdated information. do you have a URL that explains how the embedded Firebird component handles concurrency ? (something comparable to http://www.sqlite.org/lockingv3.html, that is.) /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
Re: [Python-Dev] pysqlite for 2.5?
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] interrupting my train of thought ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?! Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://[EMAIL PROTECTED]/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration (you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version). It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do: Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change). Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 _xmlplus/xmlcore and whatnot, I'd be hesitant to use the xml package as an example of _anything_ wink ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 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
Re: [Python-Dev] pysqlite for 2.5?
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 pysqlite package as top-level package, with a slight change in name to prevent clashes with the external distribution, e.g. sqlite ?! Such a module name is less likely to cause problems. Excellent point. Hm. Maybe we should just go with 'sqlite', instead. Anything, but please no db or database top-level module or package :-) Anyway, at the moment, there's 'db.sqlite' all checked in and working on a branch, at svn+ssh://[EMAIL PROTECTED]/python/branches/sqlite-integration or, if you use a readonly version http://svn.python.org/python/branches/sqlite-integration (you can use 'svn switch URL' to change a current trunk checkout to the branch without having to checkout a whole new version). It is from sqlite 2.1.3. Gerhard is cutting a 2.2.0 which reduces the requirement for the version of sqlite3 that is required. Currently, it needs 3.2.2 or later. There's tests (which pass), setup.py magic to find a correct sqlite3 version, and the like. Still to do: Windows buildproj Documentation Upgrade to the updated pysqlite once it's out maybe switch from db.sqlite to just sqlite (trivial enough change). I take it that this is not going to go into 2.5a1 ?! Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 bless a certain version of SQLite for being bugfree enough to be used until the next Python minor release. And we wouldn't want to push a Python minor release just somebody found an obscure data corroption bug in a SQLite release - SQLite might not compile on some less common platforms (AIX, HP/UX, Win64, whatever) that Python compiles fine on. - I believe Python is written in more portable C than SQLite. So it might be certain compilers that fail for compiling SQLite. - At some point you might also want a sqlite commandline shell instead of just the shared library, too. All of these are non-issues if we just compile against an installed SQLite on Unix-like system if it can be found. On Windows, I also prefer to have a dynamically linked SQLite Python module. We can distribute the SQLITE3.DLL with Python, and then people could just download an updated SQLITE.DLL from http://sqlite.org/ and overwrite the existing one of the Python installation, *if* an important bug is fixed in SQLite. Isn't the main argument for having pysqlite included in the core to be able to play around with SQL without relying on external libraries ? This, and that you can prototype without having to install and configure a database server. For many applications, the prototype can be the final version. -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 just go in the top level as 'sqlite'? I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than none at all. /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
Re: [Python-Dev] pysqlite for 2.5?
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 anyone else, or should it just go in the top level as 'sqlite'? I think sqlite is just fine. I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Will it also work with e.g. sqlite 2.8.15 (ie. sqlite v3) - this is the standard version on SuSE 9.2. Also your statement regarding sqlite3 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet. What about the Windows build ? Will that contain the necessary DLLs ? Regards, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 30 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 '1.1.6' I'm not sure how much trouble reusing this name would cause, but I'm quite sure the amount of trouble is larger than none at all. sqlitedb is not taken yet. -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 suggests that sqlite itself is not included - why not ? For the same reasons we don't include the BerkeleyDB library. Many, many modern operating systems now ship with libsqlite3 (just as they ship with bsddb). While sqlite is nowhere near the size of BerkeleyDB, it's still a non-trivial amount of code. If it works with sqlite2 then I agree: these versions are usually available on Unixes. sqlite3 is not as wide-spread yet. What about the Windows build ? Will that contain the necessary DLLs ? 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 - we could make it so that win32 Python core developers (or the Python win32 build process) don't have to build SQLite when building Python -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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. Regards, Martin ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 name right now - can anyone else, or should it just go in the top level as 'sqlite'? I think sqlite is just fine. sqlite is problematic since the old PySQLite 1.0 (2.x wrapper) had this name. But I'm in favour of a flat name too -- let's use sqlite3. Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 anyone else, or should it just go in the top level as 'sqlite'? I take it that this is not going to go into 2.5a1 ?! Well, right now the major missing bits for landing it right now are the windows build project and the documentation. I'm pretty comfortable with landing it for a1. It has tests, I've knitted these into the Python regression testing suite and they're all passing fine. I've tested building on systems with a version of sqlite that is acceptable, with no sqlite, and with an old version of sqlite, and the build process handles it all correctly. Apart from the tests issue (see python-checkins), doesn't version 1.0 of PySQLite also use the name _sqlite for its C module? If so, ours should be renamed too (_sqlite3?) to avoid breaking old apps. Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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
Re: [Python-Dev] pysqlite for 2.5?
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Windows user tjr ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 transactions to manage concurrent access by different Firebird applications. Just to make sure I wasn't imagining things, I ran two instances of a program of mine that uses Firebird, without server, accessing the same database, and both worked fine. They can independently access different parts of the database, and if they try to update the same part at the same time, deadlocks are reported as appropriate. On the whole I'm very impressed with Firebird. I've found it to be nothing less than sleek, efficient, powerful and reliable. I'd encourage anyone looking for a database, embedded or otherwise, to give it a go. -- Greg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 nobody will be trying to publish a top-level module for general use with such a generic name. In that case the application's module would just shadow the db package and the app would continue to work. If the app's author at some point wanted to start using stuff from the new db package, he would just have to rename his module. -- Greg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 and thanks from a Windows user This binary depends on msvcrt.dll. Does anybody know whether this could cause a problem? IOW, is any of the forbidden API used across the DLL boundary (in particular: memory management, stdio, locales)? Regards, Martin ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 module. I think this is how Barry does it with the email module, too. Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept. However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility. We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle. n ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Python core sqlite module. I think this is how Barry does it with the email module, too. Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept. However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. My current and future plans for pysqlite are really only additional features, like wrapping the rest of the SQLite API. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility. All my plans for pysqlite are adding more methods to the API, so I see no backwards compatibility problems. We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle. I understand your concern for keeping the amount of work for a 2.5 release manageable. So as Anthony Baxter said he'd like to work with me to make this happen, then I think he and I can try to not overload other people with more work. 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 MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here. -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 instance) db.mysqldb because of the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Python core sqlite module. I think this is how Barry does it with the email module, too. Everything Gerhard has said sounds good. From what I read it seems that it might be good to add pysqlite to the stdlib eventually. Overall, I'm +0 on the idea. It seems everyone is pretty positive on the concept. However, I'm -0 on adding this to 2.5. We've already got a lot of changes. I don't want us to keep piling more on. Also I thought I saw Gerhard say that there were some other things he wanted to finish and the timing might work better for him to defer a bit. Some of these things sounded like API changes which may be more problematic once in the core as we may have stricter rules on backwards compatibility. We also have to convert the doc from ReST to latex. None of these are show stoppers, but it adds to the amount of work we need to do before release. And there's already more work than we can handle. FWIW, I'd volunteer to convert the doc format. Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 importing works. that could be addressed by a plugin facility in db/__init__.py (or by allowing installation tools to add redirection modules to the db directory...) And I'd prefer 'database.sqlite' rather than 'db.sqlite'. and extensible_markup_language.document_object_model over xml.dom, I presume ? ;-) /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
Re: [Python-Dev] pysqlite for 2.5?
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 least for the maintenance releases. The email packages in the sandbox svn:external the library from the appropriate Python branch. The rest of the sandbox serves as a repository for all the chrome around releases, e.g. generated docs, setup.py, etc. For email 4.0 I did things a little different, treating it more like a dev branch until it was stable enough to merge back into the trunk (which reminds me, I have to twiddle the sandbox to svn:external it again). That works well for email, but you may want to do something differently. In general though, I think the sandbox is a great place to develop and release standalone packages that are also integrated with Python. So if you wanted to do something similar for pysqlite I'd be totally fine with that. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 'db.sqlite'. +1 on 'database' as the top-level package name. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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' rather than 'db.sqlite'. +1 on 'database' as the top-level package name. I think short names are more more consistent with the existing naming in the standard library. +1 on db.sqlite from me. 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. -- Gerhard ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 database.oracle there's no need to group the SQL databases. -- Michael Chermside ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 much better than nested there is no need to create a database namespace. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 that XML is *always* referred to that way in texts except for an initial expansion so people know what it stands for, whereas database is only abbreviated in limited circumstances. In addition, three characters is more visible than two. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Look, it's your affair if you want to play with five people, but don't go calling it doubles. --John Cleese anticipates Usenet ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 the result will be required, but it might be a good way to get the mechanical parts of the translation done. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 in mind? os? xml? email? Let's not get excited over names here. I say: let the RM or the BDFL, whoever feels responsible to pronounce whether PySQLite actually gets in, decide which name it will have. Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 MS VS2003, but I don't have enough experience with the Python build process to not make stupid mistakes here. I could create the VC project file if desired. Regards, Martin ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 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 have to go with no just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though... -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 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 * 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 of I personally lean somewhat toward the con side because to me it's just as easy to easy_install pysqlite after the fact, or get it from the appropriate packager (RPM, Debian, whatever). However, we can't please everybody. If we go for more batteries included, one group will complain about how much we have linked in and don't have proper system dependencies. If we go for easy to install add-ons, the same people will gripe that it's the job of the packaging system to do those add-ons, and another group will chime in that they don't have or don't want the packaging system. So we might as well flip a coin. :) ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 have to go with no just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though... Let me try to take both sides simultaneously: For: would add an SQL library to the standard distribution, and one that doesn't depend on additional infrastructure on the target machine (such as an existing database server); the author of that library is fine with including it in Python Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later. I'm sure people will add to the list if they think I omitted important points. Regards, Martin ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 argument for me? Otherwise I'll have to go with no just to err on the side of safety. I have strong feelings about the language. Sometimes I have strong feelings about the library. This doesn't seem to be one of those cases though... Let me try to take both sides simultaneously: For: would add an SQL library to the standard distribution, and one that doesn't depend on additional infrastructure on the target machine (such as an existing database server); the author of that library is fine with including it in Python Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later. More Against?: Explaining database is locked errors (due to SQLite's exposed multiple-readers/one-writer design) on a daily basis (FAQ entries notwithstanding). Robert Brewer System Architect Amor Ministries [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 an excellent choice for many kind of applications. it has no com- petition in this space. gerald's pysqlite binding is a second-generation implementation of the full DB-API (http://www.python.org/dev/peps/pep-0249/) for sqlite. 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. /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
Re: [Python-Dev] pysqlite for 2.5?
-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 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 That would be my arguments, too. Con: * Competing Python wrappers exist There is really only one other relevant wrapper: APSW. It was purposefully designed to *not* use the DB-API 2.0 (though a similar one), and being a thinner wrapper of SQLite. It wraps a few more functions of the SQLite API, though less and less, because pysqlite is catching up here. While there might be arguments for a thinner wrapper, I think that pysqlite has the advantage of being DB-API compliant (even with most optional DB-API extensions) and thus offers a good way to prototype database apps with a smooth upgrade path to other, more powerful, databases. * SQLite itself is updated frequently, let alone the wrappers SQLite being updated regularly is not really a problem, because we can link dynamically against SQLite. And we probably *should* do this on Windows, too, so users can replace a SQLite.DLL with an updated version if they wish to. * Build integration risks unknown, possible delay of 2.5? * Another external library to track and maybe have emergency updates of Emergency updates are only for security problems, right? I don't think this would apply to pysqlite. I don't think that would apply to SQLite either, but if it's conceivable, it's another argument for dynamic linking. - -- Gerhard -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEKvlzdIO4ozGCH14RAuLKAJ9BGnHz4Tym60xOGSwSuqXlqRaAdwCdFeqx +vo5eC0aBu4S2sttb/iZPOc= =bJKK -END PGP SIGNATURE- ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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
Re: [Python-Dev] pysqlite for 2.5?
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 these con arguments go for bsddb, too, and without sounding too negative about bsddb, I believe SQLite is a *much* better solution than BerkeleyDB, for roughly the same problem space. The same goes for pysqlite vs. bsddb. IMNSHO, SQLite and pysqlite are much easier to use correctly than BerkelyDB and bsddb, for simple and complex tasks. I may be biased against bsddb because I spent too much time hunting refleaks in it, but I'm not biased in favour of SQLite -- I'm a PostgreSQL user myself. ;-P I personally lean somewhat toward the con side because to me it's just aseasy to easy_install pysqlite after the fact, or get it from the appropriate packager (RPM, Debian, whatever).Actually, I have no doubt that all the package managers will split the 'bundled' pysqlite (whatever the name will be) in a separate package, just like it's done for Tkinter and bsddb and most other stdlib modules with extra dependencies. Nevertheless, adding it to the standard library is probably a good thing. I would probably choose sqlite instead of shelve/anydbm/bsddb if it were part of the standard library, even though it's probably installed on all my machines anyway. I guess it's a psych thing. As for people asking about deadlocks, well, I much rather explain about sqlite deadlocks than about BerkelyDB transactions.-- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 would be a big Batteries included plus Phillip for Python Phillip Con: Phillip * Competing Python wrappers exist Phillip * SQLite itself is updated frequently, let alone the wrappers Phillip * Build integration risks unknown, possible delay of 2.5? Phillip * Another external library to track and maybe have emergency Phillip updates of 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. Of course, that can and does happen today. Including pysqlite with Python just means it will happen more frequently. Phillip I personally lean somewhat toward the con side because to me Phillip it's just as easy to easy_install pysqlite after the fact, or Phillip get it from the appropriate packager (RPM, Debian, whatever). Is it not possible to distribute an empty db package which is then populated with various database eggs (or other similar installation things)? Skip ___ 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
Re: [Python-Dev] pysqlite for 2.5?
[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 more weird. is there *any* part of the standard Python distribution that cannot be applied to problems for which it is ill-suited? /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
Re: [Python-Dev] pysqlite for 2.5?
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 database would be wrong. I might change my mind if all stdlib packages were under some toplevel package, like stdlib. 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
Re: [Python-Dev] pysqlite for 2.5?
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 see pysqlite in 2.5 is that it follows the standard DB-API. People can start off using it, then look at switching to a larger database if their application needs grow. -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Java-like namespace packages in Python, the answer is yes. The stdlib module pkgutil supports this for regular filesystem packages, and the pkg_resources module in setuptools extends this support to zipfiles and eggs. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 Delaney ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 this work (for alpha2), Martin's willing to do the Windows build project - so I'm going to say it's going to be in 2.5. I've really not seen any arguments that convince me otherwise. Martin: Against: Adds work-load on the release process, adding more libraries to the already-large list of new libraries for 2.5. Choice of naming things is ad-hoc, but gets cast in stone by the release; likewise, choice of specific SQL library might inhibit addition of different libraries later. I'm happy to do the work (and you've said you're ok to do the windows part). All naming in the stdlib is adhoc by it's nature. We choose a name, and then that's it's name. I'm pretty happy with either 'db.sqlite' or 'database.sqlite', really. I don't think there's an alternative implementation of pysqlite bindings that could be considered for the stdlib. If an alternative to sqlite comes out some time, I don't have a problem with adding it. Phillip: * Competing Python wrappers exist There's one - and it's not DB-API compliant. I know a lot of people who use the pysqlite wrapper, I've not come across anything that uses APSW. * SQLite itself is updated frequently, let alone the wrappers * Another external library to track and maybe have emergency updates of Only an issue on platforms where we're not using the system-installed version. While sqlite gets new versions, very very few of these are security-related (I can't recall one lately) * Build integration risks unknown, possible delay of 2.5? If it's going to cause a delay, it slips until 2.6. Easy. :) Skip: 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. Of course, that can and does happen today. Including pysqlite with Python just means it will happen more frequently. Er - what? Right now, people are far more likely to use bsddb or anydbm for an inappropriate problem space. Adding a _better_ solution makes this better, not worse. I mean, adding ElementTree could also mean people will use XML in more places that are inappropriate, too, but I didn't see that raised as a problem. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 Language abbreviate it xml. People who are familiar with electronic mail abbreviate it email. And people who are familiar with the concept of a database abbreviate it db. Why are two right for the stdlib (sorry, standard library :), and the other wrong? Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 issues. Ok - well, I'm willing to work with Gerhard to do this work (for alpha2), Martin's willing to do the Windows build project - so I'm going to say it's going to be in 2.5. I've really not seen any arguments that convince me otherwise. Sounds like an excellent decision. Having it standard in the Windows build is actually going to be a big plus (though not for me personally :-). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 abbreviate it xml. People who are familiar with electronic mail abbreviate it email. And people who are familiar with the concept of a database abbreviate it db. Why are two right for the stdlib (sorry, standard library :), and the other wrong? Wow, what a world of black-and-white people we've got :-). Here's what I was thinking: db and em are too short to be useful context-free abbreviations, because there's too much chance of either conflicting with variable names in existing programs, or being confused with some other meaning for those two letters. email and xml, on the other hand, have enough real-world emphasis to be suitable. stdlib might or might not be OK (python_stdlib might be better, or pystdlib); py surely isn't. 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
Re: [Python-Dev] pysqlite for 2.5?
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
Re: [Python-Dev] pysqlite for 2.5?
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 and more weird. Fredrik is there *any* part of the standard Python distribution that Fredrik cannot be applied to problems for which it is ill-suited? 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 polluting the production database, so the folks who wanted it went the SQLite/pysqlite route. They were immediately bitten by the multiple reader/single writer limitation and they tried to cram too much data into it, so performance further sucked. Skip ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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. That suggests other database interface modules like db.mysql, db.postgresql, db.sybase, etc. Given that we probably won't include all those as standard modules, we should make it easy for someone to install one or more of those modules via normal external mechanisms and have them appear seamlessly to the Python programmer. Then I begin to wonder why bother with db.sqlite at all. Why not just create an empty db package that does the pkgutil or pkg_resources dance and let people install all N database interfaces instead of just N-1? Skip ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 infrastructure shouldn't it be done in the context of Brett's great stdlib restructuring PEP? If everything included in the stdlib is under some core package (core, stdlib, py, etc), that suggests that a package containing database wrappers would be named something like stdlib.db or py.database. The existence of a stdlib package certainly isn't a given. Still, let's assume for the moment that's how things fall out and we deliver pysqlite in the stdlib as stdlib.db.sqlite. 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 programmer has to care about stdlib vs external. (Maybe that's okay.) I'm sure there are a number of different workable solutions, but shouldn't they be considered before rather arbitrarily deciding that pysqlite belongs in db.sqlite or database.sqlite? If you're not willing to resolve the future naming scheme for 3.x or 2.6 at this point I see no reason start adding any package hierarchy(ies). Just toss it in as the sqlite module (no packaging) and be done with it. Don't start carving up the package namespace without considering the bigger picture. Skip ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 db for database stuff. It can always be renamed on import if it happens to conflict with anything in code, and I wouldn't object to not being able to have my own top-level package called db. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
[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 multiple reader/single writer limitation and they tried to cram too much data into it, so performance further sucked. 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. In fact, a Firebird interface might be an alternative worth considering for the library. It would have most of the advantages of SQLite without these disadvantages. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] pysqlite for 2.5?
[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 programmer has to care about stdlib vs external. (Maybe that's okay.) This seems to be an instance of the general problem of trying to fit a multidimensional classification into a hierarchical structure. Database systems solved this long ago by ditching the hierarchy completely and going relational. Maybe a single dotted hierarchy of package names is too restrictive? Should we be able to import things by specifying attributes instead of a pathname? import db where db.stdlib == True and db.language == SQL \ and db.interface == DBAPI2.0 ?-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 polluting the production database, so the folks who wanted it went the SQLite/pysqlite route. They were immediately bitten by the multiple reader/single writer limitation and they tried to cram too much data into it, so performance further sucked. And people trying to build production systems on SimpleHTTPServer, SimpleXMLRPCServer, smptd, or dumbdbm will also find their performance sucks. What's your point? Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 way or the other - but starting off with 'db.sqlite' (and then maybe moving/aliasing db.bsddb c at a future point) doesn't seem like a bad idea. That suggests other database interface modules like db.mysql, db.postgresql, db.sybase, etc. Given that we probably won't include all those as standard modules, we should make it easy for someone to install one or more of those modules via normal external mechanisms and have them appear seamlessly to the Python programmer. Then I begin to wonder why bother with db.sqlite at all. Why not just create an empty db package that does the pkgutil or pkg_resources dance and let people install all N database interfaces instead of just N-1? The same could be said of vast amounts of the standard library. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
[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*. :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 some decent way of writing SQL queries in Python -- not for importing, but for database access. Constructing bits of SQL out of character strings sucks *extremely* badly. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 2.6. -1 on db.sql.sqlite. Keep structure flat. Or we are eventually in a Java world with org.something.this.andthat -- bye by Wolfgang ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 off on a tangent here, but I would actually like some decent way of writing SQL queries in Python -- not for importing, but for database access. Listcomps and generator expressions are effectively equivalent to the nested domain relational calculus -- which is actually more powerful than SQL (which is based more or less on the tuple relational calculus). I've been putting off writing a genexp-to-SQL translator for some time now, but I think somebody else wrote one that actually works; I don't remember if it's SQLAlchemy or one of the other new Python ORM programs. I think it only does the subset of genexps that are easily translated to SQL, but it's certainly a start. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 the way package importing works. And I'd prefer 'database.sqlite' rather than 'db.sqlite'. +1 on 'database' as the top-level package name. I think short names are more more consistent with the existing naming in the standard library. +1 on db.sqlite from me. 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. two letter names seem short but database is a long word. long words make me thing of java. so i like 'db' ;) +1 on db.sql.sqlite. I was also about to suggest just plain sql.sqlite along the same lines as all of the one people had mentioned so far had really been SQL interfaces rather than general databases. With the bsddb module a common thing for code to do is from bsddb import db to have easy to type access to the full bsddb.db.DB object interface. that interface could migrate to live under db.berkeleydb or db.bsddb at some future point in time. -greg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 is much better than one that does, at least if the latter immediately reports conflicts if you use a zero second timeout ? /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
Re: [Python-Dev] pysqlite for 2.5?
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 updates of All of these con arguments go for bsddb, too, and without sounding too negative about bsddb, I believe SQLite is a *much* better solution than BerkeleyDB, for roughly the same problem space. The same goes for pysqlite vs. bsddb. IMNSHO, SQLite and pysqlite are much easier to use correctly than BerkelyDB and bsddb, for simple and complex tasks. I may be biased against bsddb because I spent too much time hunting refleaks in it, but I'm not biased in favour of SQLite -- I'm a PostgreSQL user myself. ;-P Agreed. sqlite is a joy to use. Its simple. It provides table structure that anyone can understand. BerkeleyDB is very powerful but requires a much more serious time investment to use usefully than sqlite for anything other than simple dictionary-like data storage. I wanted sqlite to exist for years. The intentionally undocumented bsddb.db.dbtables module i hacked together in early 2000 would never have been written had sqlite existed at the time. other things available at the time (gadfly anyone?) just didn't seem right. probably a good thing. I would probably choose sqlite instead of shelve/anydbm/bsddb if it were part of the standard library, even though it's probably installed on all my machines anyway. I guess it's a psych thing. As for people asking about deadlocks, well, I much rather explain about sqlite deadlocks than about BerkelyDB transactions. yep. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 distribution, because it's self-contained. What's people's thoughts? OTOH, +1 for a simple DB wrapper that makes it easy to start with DB-enabled applications. The trouble with it can't be worse than the BSDDB issues ;) OTOH, pysqlite2 seems to have had a fairly rapid sequence of releases in the past. That's because I decided for a more rapid release cycle than I used in the past. If bugs are fixed and no features planned to implement in the near future, I made a release. Sounds fair. I don't know whether it is now bug-free (the website claims that the 2.1 branch should be stable, and the 2.0 branch has proven stable). There have been no more bug reports since 2.1, so I'm confident that all the glitches the switch to transparent compiled statements in 2.1 introduced are fixed now. There also have been some API changes in the 2.0.x line, like the introduction of executemany() which broke e.g. SQLObject. I missed that, can you provide a link please? pysqlite 2 was announced to be incompatible with pysqlite 1. I don't think there were any backwards incompatible API changes in the 2.x line. Never mind, you're right. I had another piece of software in my head ;) Anyway, almost all popular web frameworks rely on PySQLite and seem to work well with it. Of course, speaking with Gerhard will be the way to find out more. 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 wrapping more of the SQLite API, like custom collations. In what timeframe will those be completed? I *am* willing to be a maintainer of an SQLite module for Python. I will gladly help writing a PEP for it. But I won't be the champion for the idea, because I'm only +0 on adding external libraries to Python, like elementtree, or ctypes, or pysqlite instead of relying on setuptools/Cheese Shop. I could probably be convinced that a fat Python is still a good idea nowadays, though :-) Even though setuptools are a very good concept and implementation, ships with Python is still a different kind of statement. Many people think that every external package to maintain is one too much... Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 wrapping more of the SQLite API, like custom collations. In what timeframe will those be completed? I would have waited for a pysqlite 2.2 release until I found a good API for logging for pysqlite (mainly for reporting exceptions in Python callbacks). I will probably defer the logging stuff to pysqlite 2.3 and release pysqlite 2.2 soon with the features currently in SVN. 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. If this is going to happen, I want it to happen under a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... Extensive unit tests are available, as is a reference manual in ReST format. -- Gerhard (*) Although if they're really using pysqlite 0.x/1.x then it's unlikely they'll switch to Python 2.5 with their applications. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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, because it's self-contained. SQLite/pysqlite is an awesome combination, and I do think it would make for a more compelling Python distribution. I've used it in several projects, usually with great success. My only hesitation is that in one project, we've had to stick with SQLite 3.2.1 and pysqlite 1.1.6 because we encountered some concurrency problems when trying to upgrade the former to 3.2.8. We couldn't upgrade both to the latest versions due to external project management constraints. But I'm not sure that's enough of a reason to vote against inclusion, so I guess I'm +0. Having Gerhard accept maintainership definitely pushes it from -0 to +0 in my mind. It's got lots of unit tests, so the only thing I'd probably want to see are Python docs for the module. I think Gerhard could still do more frequent releases if he wanted to -- I do that with the email package, and while it's a bit of a PITA, it's doable. Either sqlite or sqlitedb are fine names. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pysqlite for 2.5?
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 a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... db.sqlite3 ? (it wraps version 3 of the sqlite engine, after all...) /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
Re: [Python-Dev] pysqlite for 2.5?
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. What's people's thoughts? We shouldn't include anything without the explicit permission of the author(s); if possible, the authors should grant the PSF permission to change the license (i.e. fill out the contributor agreement). Even better, the authors should be willing to keep the version in Python synchronized with the separate release. Regards, Martin ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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, I want it to happen under a different package name than pysqlite2 and it's probably a good idea to skip sqlite too, because there are still users of the SQLite 1.x API (*) and this is the package name of that API. OTOH, sqlite would be the natural name if it ends up in Python. Perhaps sqlitedb ... db.sqlite3 ? That would make sense if inclusion of more database-related modules was planned. Whatever name is chosen: please no from sqlite3 import dbapi2 as sqlite! Georg ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 good idea. Whatever name is chosen: please no from sqlite3 import dbapi2 as sqlite! Amen. db.sqlite3 is the perfect name. Charles -- --- Charles Cazabon [EMAIL PROTECTED] GPL'ed software available at: http://pyropus.ca/software/ --- ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 a BDFL pronouncement? I'd say yes. If Guido even cares ;), but if not, RM pronouncement is good enough for me. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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. FWIW: http://www.rogerbinns.com/apsw.html Jean-Paul ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 is solid and widely accepted, and AFAIK has no competition. FWIW: http://www.rogerbinns.com/apsw.html That implementation doesn't support the DBAPI, although it sounds as though the differences are mostly shallow and easy to add implementations for. (e.g., implementing the fetch* methods, a description property, etc.). More likely to be an issue is that the author hasn't volunteered to contribute/support it. 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. ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 add, then it might make better sense to wait and not add either for Python 2.5. -Barry signature.asc Description: This is a digitally signed message part ___ 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
Re: [Python-Dev] pysqlite for 2.5?
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 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
Re: [Python-Dev] pysqlite for 2.5?
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 there's some general uncertainty about which to add, then it might make better sense to wait and not add either for Python 2.5. I'm not sure that there is uncertainty about *which* to add. So far we've seen a handful of +1s for pysqlite, but a link and short discussion about aspw. In my opinion, because pysqlite already has a DBAPI compliant interface to sqlite, and of us who have used it have had positive experiences, I don't see how aspw is even competition, let alone influential enough to push the adoption of an embedded SQL server to Python 2.6 or later. - Josiah ___ 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
