homepage

Since buffer() is deprecated in Python 2.7, it should not be used for BLOB input/output.
SAMPLES = (
 ('unicode', u''),
 ('bytes', ''),
 ('buffer', buffer('')),
# ('bytearray', bytearray('')), # unsupported
# ('memoryview', memoryview('')) # unsupported
)
import sqlite3
conn = sqlite3.connect(':memory:')
c = conn.cursor()
c.execute('create table test(s varchar, b blob)')
c.executemany('insert into test(s, b) values (?, ?)', SAMPLES)
c.execute('select s, b from test')
print('\n'.join(str(l) for l in c.fetchall()))
# Output:
# (u'unicode', u'')
# (u'bytes', u'')
# (u'buffer', <read-write buffer ptr 0x1d8ccd0, size 0 at 0x1d8cc80>)
#
# Errors and warnings:
# __main__:4: DeprecationWarning: buffer() not supported in 3.x
# sqlite3.InterfaceError: Error binding parameter 1 - probably unsupported type.
Here is the Python 3 input/output:
SAMPLES = ( # Python3
 ('unicode', ''),
 ('bytes', b''),
 ('bytearray', bytearray(b'')),
 ('memoryview', memoryview(b''))
)
# ('unicode', '')
# ('bytes', b'')
# ('bytearray', b'')
# ('memoryview', b'')

Sidenotes:
 - documentation for Python 3 is outdated
 - it may be a release blocker, since there's no alternative:
 currently it uses exclusively buffer() for BLOB object

buffer() is only deprecated in Python 3.x, not in Python 2.7, so the current implementation is perfectly valid for Python 2.7.
Note that buffer() has long been the preferred type for passing binary objects to and from a database.

This is not exact. buffer() doesn't exist at all in 3.x, and it issues a warning in 2.x when used with the -3 flag:
$ ./python -3
Python 2.7a2+ (trunk:77580M, Jan 17 2010, 16:51:51) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> buffer('abc')
__main__:1: DeprecationWarning: buffer() not supported in 3.x
<read-only buffer for 0x7f913ac79800, size -1, offset 0 at 0x7f913aba8570>

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> This is not exact. buffer() doesn't exist at all in 3.x, and it issues a warning in 2.x when used with the -3 flag:
> 
> $ ./python -3
> Python 2.7a2+ (trunk:77580M, Jan 17 2010, 16:51:51) 
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> buffer('abc')
> __main__:1: DeprecationWarning: buffer() not supported in 3.x
> <read-only buffer for 0x7f913ac79800, size -1, offset 0 at 0x7f913aba8570>
Sorry, that's what I meant. It's not deprecated in the 2.x branch of Python.

As far as I can see the docs for Python 3.x need to be adjusted. In particular http://docs.python.org/3.1/library/sqlite3.html#sqlite-and-python-types
buffer should then there probably be replaced by memoryview. As far as I can see, the Python 3 definition of the old "buffer" interface is "anything that I can apply memoryview to". At least that was my interpretation when doing the Python 3 port of the sqlite3 module.
Correct?
When returning BLOBs, the sqlite3 module now returns bytes objects. I think this could be changed to memoryview without causing any problems.

Hello Gerhard,
> As far as I can see, the Python 3 definition of the old "buffer"
> interface is "anything that I can apply memoryview to".
Roughly, yes.
> When returning BLOBs, the sqlite3 module now returns bytes objects. I
> think this could be changed to memoryview without causing any problems.
No, returning bytes objects is the right thing to do under py3k. This "bug" report is only about 2.x, where "bytes" is the same as "str" and therefore doesn't allow to distinguish text from binary data.

I'm attaching a correction to sqlite3 documentation, removing all 'buffer' references and setting bytes as BLOB equivalent.

Pablo's documentation patch for py3k has been committed.

So we keep buffer() as the standard way to create BLOBs for 2.x?
It is the only use of "py3k deprecated" buffer() which cannot be replaced in 2.x.
Set to "release blocker" until a decision is made.

I see that the status of this issue keeps changing.
Now does anything in the sqlite3 module or the docs need to be changed?
Or what's left to close this?

Documentation can always be updated later.

I propose to close this, since 2.7 is released and the situation is better in Python 3.