Chars / Str type

[Gustavo Niemeyer]

> To continue this really boring discussion (which originally started on
> IRC), I have some more points.

It's also interesting to point out why this isn't named Str in the first
place, and the reason is to make the migration to the upcoming Python 3.0
easier.  In Python 3.0, the "str" type will actually be used to represent
unicode values, so once Storm is ported to Python 3000, the Str property
will be another name for the Unicode property.


> I think the choice of the name "Chars" was a mistake for the 0.9
> release of Storm. I assume the choice of name was based on a context
> of knowledge of the C "char*" type, or something. There are two big
> problems with this, though:
>
> * The english word "character" doesn't restrict itself to those things
> defined in ASCII

The actual reason was because this is the closest to "string" we've got,
without naming it "Str" or "String".  It also gets close to Bytes (which
we can't use for strings because there's a 'bytes' type coming in Python
2.6+, and we'll want to support it.


> * Databases commonly use "Char" and "Varchar" to refer to *unicode*
> data, or at least auto-en/decoded data. I realized how confusing this
> was when I was drafting a table of Storm properties to database-level
> types. I had to say "For CHAR and VARCHAR types, use Unicode(); for
> BYTEA and BINARY types, use Chars()".

That's a good point that I didn't anticipate, probably because I'm
more used to seeing TEXT in these fields.


> I think "Binary" would probably be a better name for this thing than
> "Chars", even though "Binary" is a totally meaningless word when it
> comes to anything other than 0s or 1s, but at least it doesn't have
> those two major flaws.

Would anyone have a better suggestion?

-- 
Gustavo Niemeyer
http://niemeyer.net