[storm] Should storm have separate String and Blob datatypes?

[James Henstridge]

On Thu, Jul 2, 2009 at 3:12 AM, Vernon Cole<vernondcole at gmail.com> wrote:
> On Wed, Jul 1, 2009 at 9:48 AM, James Henstridge <james at jamesh.id.au> wrote:
>>
>> On Wed, Jul 1, 2009 at 10:44 PM, Gustavo Niemeyer<gustavo at niemeyer.net>
>> wrote:
>> >> Actually, Python 2.6 doesn't have a separate bytes type.  It is just
>> >> an alias for the existing byte string type:
>> >
>> [...]
>> I know that there were behaviour changes.  What I'm getting at is that
>> there are no versions of Python that have both a "str" and "bytes"
>> type
>
>
> James:
>   I don't think what you said what you meant...

Yep.  I can see what I said was a bit confusing -- I guess I still
think of Python 3's "str" as "unicode".

In the implementation, Python 3's "str" type is PyUnicode_Type (the
same as "unicode" is in Python 2).  What I meant was that there are no
Python versions with distinct PyString_Type ("str" from Python 2) and
PyBytes_Type ("bytes" from Python 3).

In fact, Python 2.6 comes with a compatibility header that #defines a
bunch of PyBytes_* APIs to the equivalent PyString_* API to aid in
porting.


> I think that the only non-confusing way during transition to Python 3 is to
> use a user-defined type for bytes of binary data.

That doesn't seem to be the approach they've taken to portability in
Python 2.6/2.7.


> Also, we should plan for an optional attribute for either the individual
> field objects, or perhaps the create_database object, to specify which
> encoding to use when converting unicode Python strings into 8-bit database
> fields.

We currently prevent you from setting a RawStr property to a unicode
value: if you want to store text (as opposed to binary data), use the
Unicode() type, and the data will be sent as text to the database.

As for databases that store text data in legacy encodings, don't they
usually handle re-encoding of text from the connection encoding?

James.