Dear Dino and Jeff:<br> I think we are all on the same wavelength. IronPython makes unicode and str the same implicitly. Python 3 makes them the same explicitly -- by getting rid of __unicode__ completely.<br> The effort to make django (or any other application) run on IronPython and the effort to make it run on Python 3 should be compatible. The same code changes should be applicable to both platforms, since they both make the same underlying change in design -- that all strings are unicode. I discovered that my efforts to make adodbapi run on IronPython went a long way toward getting it ready to run on Python 3. That's why I included a 2to3 pass on my earlier code sample. It clearly shows that IronPython's implementation of str() overshoots the mark. A tiny flaw in an amazing project. (Did you notice that CPython 2.6 raised an Encode exception while IPy raised Decode? I almost missed that.)<br>
<br>So, yes, any changes in the str vs. unicode handling of IronPython should be moves TOWARD Python 3, and should use the same syntax if possible. <br><br>Module authors should be able to do something like:<br><br>if sys.platform == 'cli' or sys.version_info[0] >= '3':<br>
def __str__(self):<br> #blah blah blah<br>else:<br> def __unicode__(self):<br> #blah blah blah<br> def __str__(self):<br> #different blah blah<br>--<br>Vernon<br>--<br>P.S.: Speaking of django, I placed an alpha-test version of adodbapi (with django compatability added) on the mercurial source tree at <a href="http://sourceforge.net/projects/adodbapi%20">http://sourceforge.net/projects/adodbapi </a>. It is heavily refactored, so I would be grateful to anyone who is willing to kick it around to see how well it holds up. All volunteers happily accepted. It should work on either IronPython or Python 3.<br>
<br>