By the way, did you the effort of porting reported on the python website:
http://wiki.python.org/moin/PortingDjangoTo3k
Seems to the good way to achieve it some times...
On Tue, Feb 2, 2010 at 5:37 PM, Dave <weber...@gmail.com> wrote:
> Ok everyone, a bit of a status update.
>
> We finished our preliminary exercise in learning Django - we created
> an architecture, performance and call profile, as well as a screencast
> instructing how to install Django in Linux and a few simple use cases.
> We'll try to make these publicly available so you the community can
> use them if you wish. Right now they're in our school's repository so
> we'll try to export them soon.
>
> Right now we're trying to decide how our work should be evaluated at
> the end of our term, April 1. What we would like to hear back from you
> is, how much do you think we should finish by that point in time?
> All / 75% / 50%, or whatever is appropriate. We're also debating how
> it should be evaluated. What made the most sense to us was to pick a
> number (if not all) of the test cases in the test suite, and try to
> have them passed by the end of term, as well as being able to perform
> some use cases. How many test cases do you think the Django / Python 3
> port should be able to pass by April 1? What use cases should a Django
> user be able to do when using the port? We were also thinking of
> making a screencast to showcase these use cases.
>
> Finally, a small aside but Martin, we tried to email you at your
> Google Group address - we were interested in talking to you about the
> work you're doing or have done on the port. Is there a way we could
> contact you in case we had some questions or needed some guidance?
>
> On Jan 15, 6:50 pm, Luke Plant <l.plant...@cantab.net> wrote:
>> On Friday 15 January 2010 18:54:51 Martin v. Löwis wrote:
>>
>> > > That sounds like a not-unreasonable distribution of work. One of
>> > > the big architecture questions is that in Django currently
>> > > anywhere you can pass a string Django will accept either a utf-8
>> > > encoded string or unicode, in Py3k given the clear
>> > > differentiation in purpose between str and bytes is that still
>> > > reasonable behavior?
>>
>> > What APIs does this refer to? There are certainly places in Django
>> > where there is no choice of providing byte strings (i.e. where you
>> > must pass Unicode strings).
>>
>> Some examples:
>>
>> >>> Template(u"{{ foo }}").render(Context({"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({u"foo":"bar"}))
>> u'bar'
>> >>> Template("{{ foo }}").render(Context({"foo":u"bar"}))
>>
>> u'bar'
>>
>> >>> MyModel.objects.filter(my_attr="foo")
>> >>> MyModel.objects.filter(my_attr=u"foo")
>> >>> mymodel_instance.my_attr = "foo"
>> >>> mymodel_instance.my_attr = u"foo"
>>
>> In addition to these things, there may be problems where dictionary
>> keys and various other values have used byte strings up until now,
>> with no problems, but based on assumptions that no longer hold. For
>> example, declarative classes (e.g. Models) are an interesting one - in
>> Python 2.x, the keys of MyClass.__dict__ are byte strings, but in 3.0,
>> they are unicode strings. Since non-ascii names for identifiers are
>> valid in Python 3.0 (thanks in part, I believe, to your good self :-),
>> and also in at least some databases, this is not an academic issue.
>>
>> Also, in Python 3.0, you can have models with non-ascii names, which
>> challenges some assumptions about things like the INSTALLED_APPS
>> setting.
>>
>> I imagine that some of these things will 'come out in the wash', so to
>> speak, and the lack of automatic conversion will help identify
>> problems, but some things might come back to bite us if we don't get
>> them right.
>>
>> Luke
>>
>> --
>> "Outside of a dog, a book is a man's best friend... inside of a
>> dog, it's too dark to read."
>>
>> Luke Plant ||http://lukeplant.me.uk/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
