Yes you are right, I should have reversed the order of my arguments on Unicode in comment #31. Python 2.x and 3.x are trying its best to deal with Unicode, but out of jealousy, I must mention that Python’s documented (too lazy to google for it, but pretty sure it’s buried somewhere in the i18n-SIG mailing list) unlikelihood of requiring ICU as a compile dependency means there’s very little chance Python will come with good collation support by default now and in the future. You just can’t beat Java’s Unicode support. But then again, it’s a moot point because no sane person will reject Python just because it doesn’t come with a module to do collation by default.

From my limited understanding of Tcl, it doesn’t seem to have the historical burdens that Python and Perl have, and due to the fact that everything in Tcl can be treated as a string, its designer probably took extra care to make sure string support is good. With that said, I wouldn’t know under what circumstance one would choose Tcl over anything.

Due to similar historical reasons, both Perl and Python 2.x’s have come up with similar ways to handle Unicode. But, I would still choose Python over Perl for the following reasons(correct me if there are better ways to do them, I never know what’s the best way to do anything in Perl):

1. I could see if a string is a unicode string by checking if isinstance(u’abc’, unicode), and u’abc’ doesn’t have to be UTF-8 encoded.
2. I don’t have to require Encode or use byte when I want to encode an Unicode string. I just do u’blah’.encode(“utf8″).

These are small ideosyntactic differences, but nonetheless I prefer.

I would only note that the Python dictionary allows for heterogeneous types as values. The burden is always on the programmer to know/test for the right type when using a dictionary. For example, in a more general case, a dictionary may return an object other than a string or list. In your specific example, your expectations didn’t meet the library designer’s choice. I’m not sure that this case by itself is an argument for having non-iterable strings.

Complaining Python cannot have good unicode support because there is no ICU on the system is pretty lame, isn’t it? Tcl’s unicode support isn’t perfect either, but if you compare it with Python or Perls its far nicer AND in a dynamical language.

(Which has some other benefits like a sane threading model with no GIL too.)

Specific to the GET dictionary example you cited, I tihnk Y.H.Wong is right: your library is at fault. Since you’re using GET, you’re extracting values from the query string. The HTTP spec expects name/value pairs in the query string. So, I don’t know why you would expect to get a list. I guess it’s possible someone could send a name twice (/foo?name1=value1&name1=value2), but this is hardly common and I don’t think it corresponds to any HTML form elements, unless they’re repeated (and then the form designer is in error).

I apologize for any strongly worded arguments but I stand by them every word. There’s no need to get testy. I’m sure we can argue our point like adults can’t we?

I can see why coming from a Perl background Python can be surprising, but then you have been programming in it for a year now. It shouldn’t be THAT surprising. As to indexing into string, I’m pretty sure you can do that with Javascript and Ruby, tho in Ruby you get back the ASCII ordinal, which is mind-boggling IMHO. In C#, you can index into anything with indexers. If you can’t understand indexible string, your head is bound to explode every time you try a C-ish language besides Java. It’s really quite common to be able to index into strings, and immensely useful in Python with slicing, so you better get used to it.

Also, indexible strings has nothing to with how a language is typed, I’m just saying you might have confused the problem with a function returning different types under different input with the problem of strings being indexible. In your specific example where you are indexing into a string where a dict maybe returning different types of sequences, it’s really just a rare corner case where the library designer chose to return multiple types that are both sequences. It’s generally frown upon to return different type because of the confusion it may cause as illustrated by your problem. A string is a sequence of characters/bytes, and a list is a sequence of things. Conceptually, in an OOP sense, they are really similar and treating them as the same when you are slicing/indexing into them is quite sensible. I suspect the BDFL would answer you similarly. It’s just because of a bad choice made by someone else in a library that you use, and an unfamiliarity with Python’s types, this confusion has arisen.

I’m not suggesting that you switch to another language, but I do suggest that you try other languages with different paradigms, and try doing things their way. It’s really a mind-opening experience.

Your suggestion that I switch languages to avoid this minor irritation is also crazy. Are there no problems in Scala, F# or Go? Of course not, they’d just be different problems! In particular there’s no way Go is mature enough to support the applications I work on. I don’t know much about Scala or F#, but somehow I doubt I’ll be able to convince the group I work with to switch!

data = { ‘foo’: ['1', '2', '3'], ‘bar’: ['400', '500', '600'] }

If you write a loop that works through the values you’re obviously going to write code like I did. And if you turn out to be wrong and the data structure is really:

data = { ‘foo’: ‘1′, ‘bar’: ‘400′ }

Then you’re going to make the mistake I did, but Python won’t notice. It’s happy to treat a string just like a list. Which is a pain. And that’s all I’m trying to say.

Oh, and please, I’m not using Snow Leopard. This is Linux, thank you very much. I suppose we’ll upgrade to a more recent v2 sometime, but we have a lot of custom RPMs that would need to be recompiled, so it’s not as easy for us as it might be for other people.