It definitely won't be in 2.6RC1 but could be in 2.6 final (or RC2 or whatever).
I'm still looking into Michael's proposed fix of recognizing calls to unicode - it's a little tricky dealing with * and **args calls to it and I got distracted by preparing for PyCon. Hopefully I can finish that up in the next couple of days and see how that works vs. just calling __unicode__ when __str__ gets called. > -----Original Message----- > From: users-boun...@lists.ironpython.com [mailto:users- > boun...@lists.ironpython.com] On Behalf Of Jeff Hardy > Sent: Wednesday, February 10, 2010 9:21 AM > To: Discussion of IronPython > Subject: Re: [IronPython] Django, __unicode__, and #20366 > > On Mon, Feb 1, 2010 at 2:46 PM, Dino Viehland <di...@microsoft.com> wrote: > > Messing with identity starts to get really scary and I'd rather not go > > there - I'm sure there will be lots of edge cases which will be broken. > > > > I could see is making unicode(foo) do something different. If you aliased > > unicode then you'd get str's behavior though but that might be perfectly > > acceptable. It's definitely a solution I had not considered and it'd > > probably fix multiple issues. > > Hi Dino, > It looks like this is a major impediment to running Django; the > majority of the test suite failures are because IronPython calls > __str__ instead of __unicode__. Any chance this could be fixed for > 2.6.1? I know it's a big change, but IMHO it's pretty critical as > well. > > - Jeff > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
