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

[Gustavo Niemeyer]

> 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

Right, but in one version of Python "str" means raw bytes, and "bytes"
means raw bytes as well, and on another one "str" actually means
unicode, and "bytes" means something newly introduced which is
incompatible.  This scheme feels like a pretty poor choice to me due
to the ambiguities.  Types are named exactly the same way, but behave
very differently.

With the naming scheme we've got in place now, there's no ambiguity.
Unicode() means only that one type we have.  RawStr() means only the
old "str" type, Str() once introduced in the future can be an alias
for Unicode() since we never had it before, and I'm hoping that we'll
introduce Bytes() with *only* the new semantics.

> The upgrade path in 2.6 is to treat "str" as the "bytes" type, so
> having a Bytes() property that represents values as 8-bit strings
> would be consistent.  And if we are using 8-bit strings as values,
> then RawStr() is that implementation.

My feeling is that just naming RawStr() as Bytes() will create an
ambiguity about what "Bytes" means and won't help the migration much
if the bytes type is actually different in 3.0, and will actually
create surprised ("But it *was* the bytes type!") but then, I'm not so
strongly attached to that whole thing either.  If you have strong
feelings that this would help people, sure, let's go.

-- 
Gustavo Niemeyer
http://niemeyer.net