You are correct. My proposal changes the way the String works. I felt that the way it currently works does not justify the name String, especially when we have Unicode class. I felt that Unicode columns should work with unicode data only, and String columns should work with regular python strings only. Documentation correctly describes what happens, but that is in my opinion wrong way to do it. I never gave much thought about String because once I saw how it works I just started using Unicode (after my patch about encoding param was accepted). But also, after seeing your proposal, I saw the opportunity to make String class behave the way I thing it should behave.

As for the autoload I'm not sure what to do. If *I* had to do it I would return Unicode columns everywhere. More flexible solution would, I guess, alow developer to intervene in some way (via kw param).

It seems to me that plain strings, in general, are used for two main reasons: lack of proper unicode support and laziness/lack of knowledge. Only after those two reasons would come all other valid reasons from knowledgable developers. I don't give much thought to those other reasons if I can use unicode. More often than not, I must use strings because of lack of unicode support, so I'm happy that SA has it. I don't consider myself unicode expert; just an unfortunate fellow who has to work with latin2 and windows-1250 encodings and somehow manage my way through. If there is somebody else here who knows more about unicode I think now would be the right time to say something...

Tvrtko

P.S. My previus post was too long so it got rejected.

Reply via email to