The following tests break:
test_str.test_conversion
We already disable a single test case (Foo9 called with
unicode) but now we would disable 3 (Foo6, Foo7, and Foo9 called with str).
Supporting it on old-style classes also causes us to disable Foo0.
test_unicode.test_conversion:
We currently disable most of the test cases here - all except
for Foo8 (Unicode)/Foo9 (str). After the change those two are failing and
everything else is now passing.
Test_traceback.test_format_exception_only_bad__str__:
BaseException defines __unicode__ and so it gets called instead
of __str__ - it looks like I can fix this one.
Test_doctest:
There's one failure here, it's the same as the test_traceback
issue, and again it looks like it's fixable.
So the net result is that tests which specifically check for differences with
__unicode__ / __str__ when called with Unicode/str change behavior. Everything
else works the same.
My initial test job didn't include support for __unicode__ on old-style classes
or have the fix for exceptions. I'm sending it through again to make sure
those two changes didn't break anything else. But I'm inclined to say that
this change is for the better. Thoughts?
> -----Original Message-----
> From: users-boun...@lists.ironpython.com [mailto:users-
> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Sunday, January 31, 2010 12:23 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Django, __unicode__, and #20366
>
> On 31/01/2010 20:14, Dino Viehland wrote:
> > I'll take a look and see what breaks if we call __unicode__ when it's
> defined
> > when the user calls str/unicode.
> >
> >
> Great. Given that *currently* IronPython will do the wrong thing I can't
> *imagine* any failures caused by this, but this probably a lack of
> imagination on my part...
>
> All the best,
>
> Michael
>
> >> -----Original Message-----
> >> From: users-boun...@lists.ironpython.com [mailto:users-
> >> boun...@lists.ironpython.com] On Behalf Of Michael Foord
> >> Sent: Sunday, January 31, 2010 11:25 AM
> >> To: Discussion of IronPython
> >> Subject: Re: [IronPython] Django, __unicode__, and #20366
> >>
> >> On 31/01/2010 01:21, Jeff Hardy wrote:
> >>
> >>> Hi all,
> >>> I've got a question regarding __unicode__ and issue #20366[0]. Django
> >>> explicitly encourages the use of __unicode__ on models[1], which
> >>>
> >> would
> >>
> >>> not be available on IronPython. Also, they have some lazy evaluation
> >>> functions that depend on differences between str and unicode, and
> >>> default to using __unicode__. Now, these differences could be worked
> >>> around in Django, but I wonder if that's the right place for them.
> >>>
> >> There's *unlikely* to be an easy fix in IronPython any time soon,
> >> although I would love to be proved wrong. The Django team have
> >> *explicitly* said that they are open to patches (or even just bug
> >> reports) to make Django compatible with IronPython.
> >>
> >>
> >>> I
> >>> also have no idea how this will play out under 3.0.
> >>>
> >>>
> >>>
> >> Django is not expecting to move to Python 3 for quite some time as I
> >> understand it.
> >>
> >>
> >>> I'm working around by checking `str is unicode`; I'm not sure there's
> >>> really a better option.
> >>>
> >>>
> >> That sounds like a good solution to me.
> >>
> >>
> >>> - Jeff
> >>>
> >>>
> >>> [0]
> >>>
> >> http://ironpython.codeplex.com/WorkItem/View.aspx?WorkItemId=20366
> >>
> >>>
> >> I still think the partial-fix I suggest in that issue would be much
> >> better than the current situation...
> >>
> >> All the best,
> >>
> >> Michael
> >>
> >>
> >>> [1]
> >>>
> >> http://docs.djangoproject.com/en/1.1/ref/models/instances/#django.db.mo
> >> dels.Model.__unicode__
> >>
> >>> _______________________________________________
> >>> Users mailing list
> >>> Users@lists.ironpython.com
> >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >>>
> >>>
> >>
> >> --
> >> http://www.ironpythoninaction.com/
> >> http://www.voidspace.org.uk/blog
> >>
> >> READ CAREFULLY. By accepting and reading this email you agree, on
> >> behalf of your employer, to release me from all obligations and waivers
> >> arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-
> >> service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-
> >> disclosure, non-compete and acceptable use policies ("BOGUS
> >> AGREEMENTS") that I have entered into with your employer, its partners,
> >> licensors, agents and assigns, in perpetuity, without prejudice to my
> >> ongoing rights and privileges. You further represent that you have the
> >> authority to release me from any BOGUS AGREEMENTS on behalf of your
> >> employer.
> >>
> >>
> >> _______________________________________________
> >> 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
> >
>
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/blog
>
> READ CAREFULLY. By accepting and reading this email you agree, on behalf of
> your employer, to release me from all obligations and waivers arising from any
> and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap,
> clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and
> acceptable use policies ("BOGUS AGREEMENTS") that I have entered into with
> your employer, its partners, licensors, agents and assigns, in perpetuity,
> without prejudice to my ongoing rights and privileges. You further represent
> that you have the authority to release me from any BOGUS AGREEMENTS on behalf
> of your employer.
>
>
> _______________________________________________
> 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
