Re: pysqlite design decisions

On 10:59 am, [email protected] wrote:

>glyph-TyWPi3/[email protected] wrote:

>| Axiom explicitly forbids use of str objects to represent text anywhere.
>|  You get unicode back from text fields, you get str objects back from
>| blob fields.
>
>Using str for blob is a bad idea!  You should use the buffer type which
>makes very unambiguous the difference between a png image and "hello
>world".  Both APSW and pysqlite return blobs as buffer.

I disagree - but I do concede that this is a very confusing decision.  What I really want to return is a mutable octet array, but Python's array module is not widely used or understood (and is missing many useful convenience functions that are present on str).

For example:

    >>> type(file('test.png', 'rb').read())
    <type 'str'>

Note that PIL's tutorial covers files and strings, but not buffers (despite having a buffer method).  This is natural, because buffers are basically useless to Python programmers, they are only useful for gluing together C programs (or extracting 'str's from).

>Back when I originally wrote APSW (December 2004) BitPim supported both
>the ANSI and Unicode versions of wxPython.  Needless to say the ANSI
>version had no idea what a Unicode string was.  Having the ASCII in,
>ASCII out mode of apsw operation meant that ANSI users of wxPython would
>work just fine providing they only ever used ASCII data.  Unicode users
>would work fine with the Unicode version.  This is all from exactly the
>same BitPim codebase without having to write any conversion code
>anywhere.  It worked really well.  It also helped people on some legacy
>platforms (eg MacOS 10.2 can't use the Unicode version of wxPython).

That's an interesting motivation.  In retrospect, I personally would still have made it explicit, rather than based on the string's content, what type apsw would return for strings (especially since if you had a database manipulated with the Unicode version and you attempted to open it with the ANSI version... what happens?) but I suppose hindsight is 20/20.

>However it is probably time to take the same approach as pysqlite and
>always return Unicode strings.  That also has the side effect of letting
>me remove code, which is my favourite thing to do with code :-)

Mine too.  Getting rid of this would simplify the axiom/apsw glue.  It just so happens I have profiled this a little as well, and the "fixup" code for converting unicode strings back to unicode was actually taking a fair amount of CPU time, making me reluctant to use apsw.

>| This opinion seems really common.  Is there a DB-API 3.0 in the works
>| that fixes some of the more obvious issues?
>
>I have no idea.  I didn't even look at DBAPI until apsw was almost
>finished.  My goal has always been an SQLite interface, not a generic
>database layer.

I am similarly disinterested, so I will refrain from further commentary on it, since I am almost certainly not going to do anything productive in this area.

_______________________________________________
pysqlite mailing list
pysqlite-IAPFreCvJWPBWskQ1e/[email protected]
http://lists.initd.org/mailman/listinfo/pysqlite