将pysqlite2包含在Python 2.5中？ [英] Include pysqlite2 into Python 2.5?
问题描述
[这是从消息到用户列表中的python-dev的转发，
因为python-dev-ers认为对此更广泛的讨论是好的
想法。]
去年12月，我们有一个简短的线程讨论（在python-dev中）将PySQLite集成到Python 2.4中的
。当时，我反对支持
，因为我认为PySQLite并不成熟，大多数是因为我认为API不稳定所以。
现在，我已经开始编写一个新的PySQLite模块，它具有
以下主要功能：
- 使用迭代器风格SQLite 3.x API：sqlite3_compile，sqlite3_step（）
等。这样，就可以使用预处理语句，对于
大型结果集，它需要更少的内存，因为整个
结果集不会再被提取到内存中。
- 完全与SQLite 0.x / 1.x API不兼容：我现在可以自由地使用
创建一个更好的API。
- 面对歧义，拒绝猜测的诱惑。 ; -
PySQLite 1.x试图猜测要转换为哪种Python类型。它是非常好的，因为它查询列类型信息。
这适用于，我会说至少90％的情况。但是只要
你使用像
SQL中的函数，聚合或表达式这样的东西，SQLite的_typeless_性质就会突破，它会告诉
我们没有关于声明的列类型（当然，因为
数据不是来自数据库列）。
所以我决定改变默认行为并默认使PySQLite
无类型。所有内容都将作为Unicode
字符串返回（默认情况下可能是每个连接的用户可配置）。
除非，除非用户明确激活
" guess-mode" ;-)但要这样做，她必须阅读文档，然后她将会知道它只能在90％的情况下工作。
那么为什么我为此烦恼呢？
我认为一个简单的嵌入式关系数据库在Python中默认是一个很好的东西。而且随着Python 2.5不会很快发生
，有足够的时间来开发它，让它稳定，并整合它。
特别是那些过去曾使用过PySQLite的人，你是否b / b $ b有任何建议可以让重写成为更好的候选人
包含在Python中？
我看到的一个问题是，即使是新的PySQLite也会增长并尝试将
包装成大部分非直接的SQLite API与
DB-API相关。如果这样的东西对于标准的
库来说太复杂/太大了，那么生成一个更简单的
PySQLite会更好，特别是对于Python标准库而言留下所有花哨的东西。我的代号是embsql。
那么，你想看到什么？ import sqlite，import embsql或
" pypi.install（''pysqlite''）" ？
- Gerhard
----- BEGIN PGP SIGNATURE -----
版本：GnuPG v1.2.4（GNU / Linux）
iD8DBQFBd2 / EdIO4ozGCH14RAhKpAJ9F33gxhA2j + y / CeuKe0wvFpRZAKwCePMEL
dzvLQjiR6GaRS8M3eq2GXYY =
= SEKQ
----- END PGP SIGNATURE -----
>>> ;>> "格哈德" == Gerhard Haering< gh@ghaering.de>写道：
去年12月，我们讨论了一个简短的线程（在python-dev中）将PySQLite集成到Python 2.4中。当时，我反对包含，因为我认为PySQLite并不成熟，主要是因为我认为API不稳定。
感谢您使用PySQLite并祝贺您达到1.0里程碑。我到目前为止
只用PySQLite进行过实验，但是对于任何未来的项目来说它肯定都在我的
工具箱中:-)。
我我认为默认情况下，一个简单的嵌入式关系数据库在Python中是个好东西。因为Python 2.5不会很快发生，所以有足够的时间来开发它，使它稳定并集成它。
+1。 bsddb就在那里，SQLite绝对值得包括在内。一个免费的
许可证，没有设置，易于使用 - 你还能要求什么:-)。
特别是那些曾经使用过PySQLite的人，做的你有什么建议可以让重写成为更好的候选人吗？
我没有广泛使用它来获得有意义的建议。我的
个人感觉不是使用PySQLite API而是使用DB-API 2.0。正如在另一个帖子中提到的那样，某个人（另外一个人）提到了一个（可能是两个）强制性的参数样式，这是一个很高的时间Python
。 />
我看到的一个问题是，即使是新的PySQLite也会增长并尝试包装大部分与
DB-API没有直接关系的SQLite API。如果这样的事情对于标准的库来说太复杂/太大了，那么生成一个更简单的PySQLite会更好，特别是对于那些让所有人都感到奇怪的Python标准库东西。我的代号是embsql。
所以，你想看到什么？ import sqlite，import embsql或
pypi.install（''pysqlite''）" ？
导入sqlite
Ganesan
Gerhard Haering写道：
特别是那些过去使用过PySQLite的人，你是否有任何建议可以让重写成为更好的候选者？ ？
好主意！
我目前正处于移动申请的计划阶段
来自关系数据库通过PySQL到SQLite。我认为
嵌入式，支持SQL的数据库是下一个重要的事情
只需要管理一个
$ b就会感到很痛苦$ b大数据库，当你真的不需要它们时....
我看到的一个问题是即使是新的PySQLite也会增长并尝试包装大部分SQLite API与
DB-API没有直接关系的。如果这样的事情对于标准的库来说太复杂/太大了，那么生成一个更简单的PySQLite会更好，特别是对于那些让所有人都感到奇怪的Python标准库东西。我的代号是embsql。
那么，你想看到什么？ import sqlite，import embsql，或者
我认为导入sqlite会是明智之举。就像你说的那样......
....拒绝猜测的诱惑...
Istvan。
好主意和时间。 Python需要某种类型的默认SQL引擎。我没有回顾你在做什么，但我可以建议你看看VFP用它的内置数据引擎做了什么。 VFP使用
游标的概念以及许多内置命令/函数/语句来处理
数据。
我唯一的问题是当SQLLite失宠时会发生什么，即TK
今天是什么？
John
[This is a repost from a message to python-dev on the users'' list,
because python-dev-ers thought a broader discussion of this is a good
idea.]
Last December, we had a short thread discussing (in python-dev) the
integration of PySQLite into Python 2.4. At the time, I was against
inclusion, because I thought PySQLite was not ripe for it, mostly
because I thought the API was not stable.
Now, I have started writing a new PySQLite module, which has the
following key features:
- Uses iterator-style SQLite 3.x API: sqlite3_compile, sqlite3_step()
etc. This way, it is possible to use prepared statements, and for
large resultsets, it requires less memory, because the whole
resultset isn''t fetched into memory at once any longer.
- Completely incompatible with the SQLite 0.x/1.x API: I''m free to
create a much better API now.
- "In the face of ambiguity, refuse the temptation to guess." -
PySQLite 1.x tries to "guess" which Python type to convert to. It''s
pretty good at it, because it queries the column type information.
This works for, I''d say 90 % of all cases at least. But as soon as
you use anything fancy like functions, aggregates or expressions in
SQL, the _typeless_ nature of SQLite breaks through and it will tell
us nothing about the declared column type (of course, because the
data is not coming from a database column).
So I decided to change the default behaviour and make PySQLite
typeless by default, too. Everything will be returned as a Unicode
string (the default might be user-configurable per connection).
Unless, unless of course the user explicitly activates the
"guess-mode" ;-) But to do so, she must read the docs then she will
be aware of the fact that it only works in 90 % of all cases.
So why am I bothering you about this?
I think that a simple embedded relational database would be a good
thing to have in Python by default. And as Python 2.5 won''t happen
anytime soon, there''s plenty of time for developing it, getting it
stable, and integrating it.
Especially those of you that have used PySQLite in the past, do you
have any suggestions that would make the rewrite a better candidate
for inclusion into Python?
One problem I see is that even the new PySQLite will grow and try to
wrap much of the SQLite API that are not directly related to the
DB-API. If such a thing is too complicated/big for the standard
library, then maybe it would be better to produce a much simpler
PySQLite, especially for the Python standard library that leaves all
the fancy stuff out. My codename would be "embsql".
So, what would you like to see? "import sqlite", "import embsql", or
"pypi.install(''pysqlite'')" ?
-- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBd2/EdIO4ozGCH14RAhKpAJ9F33gxhA2j+y/CeuKe0wvFpRZAKwCePMEL
dzvLQjiR6GaRS8M3eq2GXYY=
=SEKQ
-----END PGP SIGNATURE-----
>>>>> "Gerhard" == Gerhard Haering <gh@ghaering.de> writes:
Last December, we had a short thread discussing (in python-dev) the
integration of PySQLite into Python 2.4. At the time, I was against
inclusion, because I thought PySQLite was not ripe for it, mostly
because I thought the API was not stable.
Thank you for PySQLite and congratulations for reaching the 1.0 milestone. I
have only experimented with PySQLite so far but it''s definitely in my
toolbox for any future projects :-).
I think that a simple embedded relational database would be a good
thing to have in Python by default. And as Python 2.5 won''t happen
anytime soon, there''s plenty of time for developing it, getting it
stable, and integrating it.
+1. bsddb is in there and SQLite definitely deserves to be included. A free
license, no setup, easy to use - what more can you ask for :-).
Especially those of you that have used PySQLite in the past, do you
have any suggestions that would make the rewrite a better candidate
for inclusion into Python?
I have not used it extensively to be able to get meaningful suggestions. My
personal peeve is not with the PySQLite API but with DB-API 2.0. As some one
(Alex Martelli?) mentioned in another thread, it''s high time Python
standardized on one (may be two) mandatory param styles.
One problem I see is that even the new PySQLite will grow and try to
wrap much of the SQLite API that are not directly related to the
DB-API. If such a thing is too complicated/big for the standard
library, then maybe it would be better to produce a much simpler
PySQLite, especially for the Python standard library that leaves all
the fancy stuff out. My codename would be "embsql". So, what would you like to see? "import sqlite", "import embsql", or
"pypi.install(''pysqlite'')" ?
import sqlite
Ganesan
Gerhard Haering wrote:
Especially those of you that have used PySQLite in the past, do you
have any suggestions that would make the rewrite a better candidate
for inclusion into Python?
great idea!
I''m currently in the planning phase of moving an application
from a relational database to SQLite via PySQL. I think
embedded, SQL capable databases are "the next big thing"
there is just to much pain being felt by having to manage a
big database when you don''t really need them ....
One problem I see is that even the new PySQLite will grow and try to
wrap much of the SQLite API that are not directly related to the
DB-API. If such a thing is too complicated/big for the standard
library, then maybe it would be better to produce a much simpler
PySQLite, especially for the Python standard library that leaves all
the fancy stuff out. My codename would be "embsql".
So, what would you like to see? "import sqlite", "import embsql", or
I think import sqlite would be the sensible thing. Just as you said ...
.... refuse the temptation to guess ...
Istvan.
Great idea and about time. Python needs some type of default SQL engine. I
have not reviewed what you are doing but may I suggest you take a look at
what VFP did with it''s built-in data engine. VFP uses the concept of a
cursor along with many built-in commands/functions/statements to work with
the data.
My only question is what happens when SQLLite becomes out of favor i.e. TK
is today?
John
这篇关于将pysqlite2包含在Python 2.5中？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
