Porting Django to Python 3

[Dave]

Hello everyone,

My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.

Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.

A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.

We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Best regards,

Dave Weber

[Jerome Leclanche]

Best of luck in your port.

On that note, I'm hoping when the 3k port will be officially supported, it
will not be backwards compatible. The core idea of 3k itself is the lack of
backwards compatibility ...

J. Leclanche / Adys

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.
Best regards,
Dave Weber
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

[VernonCole]

Dave:
Wonderful! I am presently working on a project to get adodbapi
(http://sourceforge.net/projects/adodbapi) working in django. That
may be important to you since it is one of few db interfaces which has
a working python 3 version for Windows. Keep in touch.
--
Vernon Cole

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.
Best regards,
Dave Weber

[Russell Keith-Magee]

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Hi Dave,

Sounds like an interesting project!

My best piece of advice would be to learn to love the test suite.
Django's test suite may take a long time to run, but it is quite
comprehensive, and has enabled us to complete several large internal
refactoring projects with a minimum of impact on the general user
community.

My other advice would be to get involved in the community. Don't just
treat your Python 3 port as "your CS project", independent of the rest
of the world. For example, if your porting efforts discovers a section
of code that isn't tested (or tested well), or you discover a simple
fix that will boost performance, don't be a stranger - submit a patch
and help us make Django better.

This even extends to documentation - if your porting efforts generate
architecture documentation that might be useful to the general
community, we'd love to have that contributed back to the community.

Best of luck with your project. I can't wait to see what you come up with :-)

Yours,
Russ Magee %-)

[Jesus Mager]

Hi all!

I'm CS student at the National Autonomous University of Mexico, and
I'm very interested to porting Django to Python 3 too. I hope the
efforts porting Django will be public on a svn branch, so I can also
collaborate. And of course, if a core developer can guide us, it will
be much better.

Post by Russell Keith-Magee

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Hi Dave,
Sounds like an interesting project!
My best piece of advice would be to learn to love the test suite.
Django's test suite may take a long time to run, but it is quite
comprehensive, and has enabled us to complete several large internal
refactoring projects with a minimum of impact on the general user
community.
My other advice would be to get involved in the community. Don't just
treat your Python 3 port as "your CS project", independent of the rest
of the world. For example, if your porting efforts discovers a section
of code that isn't tested (or tested well), or you discover a simple
fix that will boost performance, don't be a stranger - submit a patch
and help us make Django better.
This even extends to documentation - if your porting efforts generate
architecture documentation that might be useful to the general
community, we'd love to have that contributed back to the community.
Best of luck with your project. I can't wait to see what you come up with :-)
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Joshua Partogi]

Post by Russell Keith-Magee

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Hi Dave,
Sounds like an interesting project!
My best piece of advice would be to learn to love the test suite.
Django's test suite may take a long time to run, but it is quite
comprehensive, and has enabled us to complete several large internal
refactoring projects with a minimum of impact on the general user
community.
My other advice would be to get involved in the community. Don't just
treat your Python 3 port as "your CS project", independent of the rest
of the world. For example, if your porting efforts discovers a section
of code that isn't tested (or tested well), or you discover a simple
fix that will boost performance, don't be a stranger - submit a patch
and help us make Django better.
This even extends to documentation - if your porting efforts generate
architecture documentation that might be useful to the general
community, we'd love to have that contributed back to the community.
Best of luck with your project. I can't wait to see what you come up with :-)
Yours,
Russ Magee %-)

Russ,

Would it be possible if the django core developers to create a python3
branch in the django svn repository?

Kind regards,

--
http://jobs.scrum8.com | http://twitter.com/scrum8

[Alex Gaynor]

On Tue, Jan 12, 2010 at 10:52 PM, Joshua Partogi

Post by Joshua Partogi

Post by Russell Keith-Magee

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

Hi Dave,
Sounds like an interesting project!
My best piece of advice would be to learn to love the test suite.
Django's test suite may take a long time to run, but it is quite
comprehensive, and has enabled us to complete several large internal
refactoring projects with a minimum of impact on the general user
community.
My other advice would be to get involved in the community. Don't just
treat your Python 3 port as "your CS project", independent of the rest
of the world. For example, if your porting efforts discovers a section
of code that isn't tested (or tested well), or you discover a simple
fix that will boost performance, don't be a stranger - submit a patch
and help us make Django better.
This even extends to documentation - if your porting efforts generate
architecture documentation that might be useful to the general
community, we'd love to have that contributed back to the community.
Best of luck with your project. I can't wait to see what you come up with :-)
Yours,
Russ Magee %-)

Russ,
Would it be possible if the django core developers to create a python3
branch in the django svn repository?
Kind regards,
--
http://jobs.scrum8.com | http://twitter.com/scrum8
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

I'm not a core developer, but my perspective on the matter is, why?
Branches in Django's SVN are usually either from core developers or
other individuals working on projects specifically endorsed, and
mentored by core developers (such as GSOC). As such I think the most
sensible course of action would be to work on an external repo, on
something like github, bitbucket, or google code.

Alex

[Tobias McNulty]

I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Sent from a mobile phone, please excuse any typos.
everyone, > > > My name...
Russ,

Would it be possible if the django core developers to create a python3
branch in the django svn repository?

Kind regards,

--
http://jobs.scrum8.com | http://twitter.com/scrum8

--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to
django-developers+unsubscribe-/***@public.gmane.org<django-developers%2Bunsubscribe-/***@public.gmane.org>
.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

[Hanne Moa]

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.


HM

[Russell Keith-Magee]

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I can't think of any case where Django *requires* old-style classes.
Old-style classes are certainly used, but that's a combination of
accident, historical implementation and a small dose of clean API
styling ("class Meta" is cleaner and clearer than "class
Meta(object)"). I can't think of any reason why Django's current usage
of old-style classes couldn't be migrated to new-style classes.

Yours,
Russ Magee %-)

[Karen Tracey]

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be

the

Post by Tobias McNulty
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option. This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
in late 2008:

http://wiki.python.org/moin/PortingDjangoTo3k

He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source. It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.

Karen

[VernonCole]

Having survived the update of pywin32 to python 3, let me say that
both comments are correct:
1) you do NOT create a fork, you convert the existing code so that it
will run through 2to3
2) it takes a LOT of hand refactoring of older 2.x code to get ready
for 2to3.
and, may I add:
3) it's worth the work. The refactoring tends to clean up rough edges
that have been hanging around the old code from long, long ago.
IMHO it is absolutely necessary for one or more core developers to be
intimately involved with the conversion. Such things as conversion to
new style classes and byte buffer creation objects will very likely
reach into a majority of the existing modules, so the volume of
patches will be very large. If these patches are not integrated into
the tip branch(es) rapidly, it is likely that new work will get very
confusing. I personally found it very helpful to incorporate
suggestions from the guys doing the 2-to-3 conversion directly into
the development branch I was working on -- so that within a day my
development branch became the 2-to-3 conversion branch as well. By
the time I finished my next incremental update, it was 2to3 ready.

Cheering from the sidelines is not enough.

By the way, the pywin32 modules work in all versions of Python from
2.3 to 3.1 (mine works in IronPython as well.) 2.6 is helpful for a
conversion effort, but not necessary.
--
Vernon Cole

Post by Karen Tracey

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be

the

Post by Tobias McNulty
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option.  This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
http://wiki.python.org/moin/PortingDjangoTo3k
He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source.  It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.
Karen

[Josh Roesslein]

From my experience with the 2to3 tool, it's no silver bullet for

porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.

I'd think doing the initial porting be done with Git or such to allow
for better collaboration.
Once the porting is done it should be moved into Django's SVN as a
seprate branch with an assigned
manager(s) who's duty is to merge in any changes in the 2.x branch.
While this might sound taxing, it's fairly
easy to do and can even be automated in some cases. Simply when ever a
commit occurs in 2.x auto apply it to
the 3.x branch then run the tests. If all pass, finalize the commit
and be done. If tests fail, fire off an error email to the person
responsible for the 3.x branch so they can fix it. You can even run
the 2to3 tool to try fixing any issues.

So

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option.  This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
http://wiki.python.org/moin/PortingDjangoTo3k
He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source.  It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

[Jesus Mager]

Hi!

I don't think we can have a library working on python 2 and at the
same time on python 3.(Dont know if 3to2 is a good solution). The
converting process, IMHO, should be prepared for a mayor release of
Django, may be django 2 and let python 2 without support for these
version. But maintaining 2 libraries at the same time will be really
confusing.
I Know, Django 1.x is at now very young, but, what about starting the
ideas for the nee mayor release.
Just ideas...

From my experience with the 2to3 tool, it's no silver bullet for
porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.
I'd think doing the initial porting be done with Git or such to allow
for better collaboration.
Once the porting is done it should be moved into Django's SVN as a
seprate branch with an assigned
manager(s) who's duty is to merge in any changes in the 2.x branch.
While this might sound taxing, it's fairly
easy to do and can even be automated in some cases. Simply when ever a
commit occurs in 2.x auto apply it to
the 3.x branch then run the tests. If all pass, finalize the commit
and be done. If tests fail, fire off an error email to the person
responsible for the 3.x branch so they can fix it. You can even run
the 2to3 tool to try fixing any issues.
So

Post by Karen Tracey

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option.  This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
http://wiki.python.org/moin/PortingDjangoTo3k
He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source.  It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
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.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Łukasz Rekucki]

Post by Jesus Mager
Hi!
I don't think we can have a library working on python 2 and at the
same time on python 3.(Dont know if 3to2 is a good solution).

It is possible to write 3.x code that is backwards-compatible with
python 2.6+. There are some rough edges like, names of stdlib modules,
instance checks for strings and some introspection details. In my
opinion, it's pretty much the same as supporting old 2.x pythons.

Post by Jesus Mager
The converting process, IMHO, should be prepared for a mayor release of
Django, may be django 2 and let python 2 without support for these
version. But maintaining 2 libraries at the same time will be really
confusing.
I Know, Django 1.x is at now very young, but, what about starting the
ideas for the nee mayor release.
Just ideas...

As a Django user I would be very unhappy to know, that after spending
lots of time making my app python 3.x compatible, now I have to port
it to a newer backwards-incompatible Django2 (and again, wait for all
applications I use to do the same).

Post by Jesus Mager

From my experience with the 2to3 tool, it's no silver bullet for
porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.
I'd think doing the initial porting be done with Git or such to allow
for better collaboration.
Once the porting is done it should be moved into Django's SVN as a
seprate branch with an assigned
manager(s) who's duty is to merge in any changes in the 2.x branch.
While this might sound taxing, it's fairly
easy to do and can even be automated in some cases. Simply when ever a
commit occurs in 2.x auto apply it to
the 3.x branch then run the tests. If all pass, finalize the commit
and be done. If tests fail, fire off an error email to the person
responsible for the 3.x branch so they can fix it. You can even run
the 2to3 tool to try fixing any issues.
So

Post by Karen Tracey

Post by Hanne Moa

Post by Tobias McNulty
I am by no means an expert on the matter, but I remember seeing a comment
awhile back suggesting that it generally makes more sense to fix the 2to3
script than to maintain two branches of the same library. Might that be the
case here as well?

Py3K does not support old-style classes. Django uses these quite a
lot, for instance the Meta-class of a model is old-style. I don't
think it is in any way possible to have an automatic script convert
these in a sensible way as django is deliberately utilizing the
difference between old and new style in no doubt a django-specific
way. If django on 2.x could be rewritten to no longer depend on
old-style classes, and was made to depend on python 2.6 or newer, then
2to3 would have a chance to do its magic.

I'm no expert either, but as I understanding it maintaining single source
for 2.x (where x can be lower than 6) and 3.x and using 2to3 to generate the
3.x version during install may be a viable option.  This is the approach
that was taken by Martin v. Löwis when he got an initial port working back
http://wiki.python.org/moin/PortingDjangoTo3k
He cites bugs in 2to3 as a barrier to getting the approach to work at that
time, but doesn't note anything insurmountable he ran across in the Django
source.  It is true the port only verified that getting through the tutorial
worked, but that covers the basics of models certainly.
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
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.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

--
Jesus Mager
[www.h1n1-al.blogspot.com]
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Marty Alchin]

Post by Łukasz Rekucki
It is possible to write 3.x code that is backwards-compatible with
python 2.6+. There are some rough edges like, names of stdlib modules,
instance checks for strings and some introspection details. In my
opinion, it's pretty much the same as supporting old 2.x pythons.

In many cases, this is true, but there are other scenarios (certain
forms of exception handling, for example) where there is no syntax
that's valid in both versions. That's syntax, not just libraries and
functions. There's no way to even get a file to parse in both Python 2
and Python 3 in these situations. There are certainly places in Django
that will run into these, so we really can't have a single codebase
that's completely compatible with both branches.

-Gul

[Karen Tracey]

Post by Marty Alchin

Post by Łukasz Rekucki
It is possible to write 3.x code that is backwards-compatible with
python 2.6+. There are some rough edges like, names of stdlib modules,
instance checks for strings and some introspection details. In my
opinion, it's pretty much the same as supporting old 2.x pythons.

In many cases, this is true, but there are other scenarios (certain
forms of exception handling, for example) where there is no syntax
that's valid in both versions. That's syntax, not just libraries and
functions. There's no way to even get a file to parse in both Python 2
and Python 3 in these situations. There are certainly places in Django
that will run into these, so we really can't have a single codebase
that's completely compatible with both branches.

Martin's approach was single codebase where the 3.x version for execution is
generated by 2to3, not single source for execution across 2.x and 3.x. Thus
I'm wondering if this difference is accounted for by 2to3? If yes, then it
is not necessarily a problem that would stand in the way of maintaining
single Django source and supporting Python 2.x and 3.x simultaneously.

Karen

[Marty Alchin]

Post by Karen Tracey
Martin's approach was single codebase where the 3.x version for execution is
generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
I'm wondering if this difference is accounted for by 2to3?  If yes, then it
is not necessarily a problem that would stand in the way of maintaining
single Django source and supporting Python 2.x and 3.x simultaneously.

Yes, I was a bit less clear than I should've been. I was responding on
an assumption that the author was expecting a single codebase to work
with 2 and 3 without going through 2to3 in between. To my knowledge,
2to3 does handle all the syntactic issues between the two, but I just
wanted to make it clear that it's definitely not "pretty much the same
as supporting old 2.x pythons."

-Gul

[Łukasz Rekucki]

Post by Marty Alchin

Post by Karen Tracey
Martin's approach was single codebase where the 3.x version for execution is
generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
I'm wondering if this difference is accounted for by 2to3?  If yes, then it
is not necessarily a problem that would stand in the way of maintaining
single Django source and supporting Python 2.x and 3.x simultaneously.

Yes, I was a bit less clear than I should've been. I was responding on
an assumption that the author was expecting a single codebase to work
with 2 and 3 without going through 2to3 in between.

That is what I meant. And I believe it is possible even with those
syntactic diffrences.

Post by Marty Alchin
To my knowledge,
2to3 does handle all the syntactic issues between the two, but I just
wanted to make it clear that it's definitely not "pretty much the same
as supporting old 2.x pythons."

I'm not saying it is *as easy*. Surely, it's more complicated and
requires more work.

And actually, I agree with that 2to3 already handles most of this
stuff, so it's the right way to go. At least now. What I really wanted
to say, is that using 2to3 on a 2.6 code that uses (for example)
__future__.unicode_literals is more likely to succed.

Post by Marty Alchin
-Gul

[Martin v. Löwis]

Post by Karen Tracey

Post by Marty Alchin
In many cases, this is true, but there are other scenarios (certain
forms of exception handling, for example) where there is no syntax
that's valid in both versions. That's syntax, not just libraries and
functions. There's no way to even get a file to parse in both Python 2
and Python 3 in these situations.

Martin's approach was single codebase where the 3.x version for execution is
generated by 2to3, not single source for execution across 2.x and 3.x.  Thus
I'm wondering if this difference is accounted for by 2to3?

Most certainly - that's the whole *point* of 2to3. Converting the
cases where
the syntax differs are actually the easy parts - it is very easy to
find out, by
static analysis, that Python 3 would reject a piece of code, and to
propose
a reformulation that is equivalent. That's where 2to3 shines, and thus
where
anybody adding 3.x support to a 2.x code base doesn't need to worry at
all.

When the syntax is correct in both versions, but library names
differs, 2to3
still works fairly well if it guesses correctly that the name indeed
refer to the
renamed libraries (which has some degree of uncertainty in Python).

The really difficult cases for 2to3 is where a piece of code works
unmodified
in both 2.x and 3.x, but does something significantly different. For
example,
string literals mean something different, and the result of reading
from a file
may be different (unicode vs. bytes in both cases). Fortunately,
Django
already attempts to differentiate bytes and unicode fairly well, so it
was
easy to fix the remaining spots which would break under 3.x.

Regards,
Martin

[Karen Tracey]

Post by Jesus Mager
Hi!
I don't think we can have a library working on python 2 and at the
same time on python 3.(Dont know if 3to2 is a good solution). The
converting process, IMHO, should be prepared for a mayor release of
Django, may be django 2 and let python 2 without support for these
version. But maintaining 2 libraries at the same time will be really
confusing.
I Know, Django 1.x is at now very young, but, what about starting the
ideas for the nee mayor release.
Just ideas...

Again, this is the approach that was taken by Martin v. Löwis when he got an
initial port working back in late 2008:

http://wiki.python.org/moin/PortingDjangoTo3k

Single source supporting 2.x through 3.x, the 3.x version generated during
install by 2to3. At that time Martin did not report finding any
show-stoppers that would prohibit this approach from working. He cites some
bugs in 2to3, bugs that I assume have been fixed by now. Given that prior
positive-sounding experience, I don't see why this approach should be
rejected out-of-hand with statements like "I don't think it can work". I'd
really like to hear some concrete reasons, backed by specific problems, for
why this can't work before seeing it rejected.

I also don't think it will be feasible for Django, in a single version step,
to switch from saying "we support Python 2.x through whatever is latest in
the 2.x line" to "we support Python 3.x only". I believe both will need to
be supported simultaneously for some amount of time. Finding the least
painful way of doing that is important, in my opinion.

Karen

[VernonCole]

Just a note to clarify my earlier comment...
I was one of the developers who went through the experience of making
pywin32 Python 3 compatible, so I hope my experience can be of some
benefit to this group as well.
Note that I did not say "made a Python 3 version of pywin32" because
that is the wrong way to think about the project. What you do is
refactor the Python 2 code so that (after running through 2to3) it
will ALSO work in Python 3. In our project, Mark did use a DVCS to
collect all of our patches but then ran the refactored source back
into the CVS tree on sourceforge as soon as possible. It turned out
to be a lot of trouble porting the changes originally made in our
abortive "Python 3" branch back into the main development trunk, where
the work was finally completed.

2to3 has lots of command line switches which you use to coerce it
into giving the translation details you need, so you fix your Python2
code so that you NEVER edit the output of 2to3.

Someone mentioned a possible C-language-preprocessor-like syntax.
There isn't one. In those cases where the two versions require
different code, a normal Python "if" statement is used.
For example, here is a function which accepts a string (or unicode
string) and returns a binary buffer (i.e. type 'str' in CPython2 or
IronPython, but class 'bytes' in Python 3):

def str2bytes(sval):
if sys.version_info < (3,0) and isinstance(sval, str):
sval = sval.decode("latin1")
return sval.encode("latin1")

Then, inside the Python 2 code, you track down all implicit uses of a
string to create a binary buffer, and replace them with an explicit
function call like:

binfld = str2bytes('\x00\x01\xE2\x40')

Which not only works in either dialect of Python, but also is easier
for a code reviewer to understand.
--
Vernon

[Karen Tracey]

From my experience with the 2to3 tool, it's no silver bullet for
porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.
In the cases where you had to do manual tweaking, it sounds like you

tweaked the output of the 2to3 tool. Could you instead have changed the
original source in some way so it would both still work on 2.x and have 2to3
generate the correct code for 3.x?

Karen

[Alex Gaynor]

From my experience with the 2to3 tool, it's no silver bullet for
porting to 3. I have had plenty of cases where manual tweeking of the
code was needed. The tool does help a lot on getting trivial things
changed over, but certain things it just can't do. Now this is with a
very small library of mine, django is a lot more complex.

In the cases where you had to do manual tweaking, it sounds like you tweaked
the output of the 2to3 tool. Could you instead have changed the original
source in some way so it would both still work on 2.x and have 2to3 generate
the correct code for 3.x?
Karen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.

I thought there was a way to have comments of the form:

# PY2
some code
# PY3
# some code
# ENDPY

Or something like that, and 2to3 handled them correctly.

Alex

[Johan]

Hello everyone,

My name is Johan Harjono, and I'm one of the UofT students
who will be taking part in porting Django to Python 3. It's a pleasure
to meet you all and I hope I will not be asking too many stupid
questions :)

regards,
Johan Harjono

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.
Best regards,
Dave Weber

[Graham Dumpleton]

Post by Dave
Hello everyone,
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.
Until the end of January, we'll be studying the existing Django code
in order to gain an understanding of how the program works. We'll be
doing this primarily through architecture documentation and
performance profiling. In early February we plan on beginning work on
the port.
A few of us have experience working with Django, and by the end of
January we should have a much better understanding of it. I've been in
touch with Jacob Kaplan-Moss, who pointed me to this group, and he
also provided me with links about contributing to the Django project
and Martin van Lowis' port.
We don't really have any specific questions right now as we're pretty
unfamiliar with most of the project at this point in time. However, we
are very eager to learn as much as we can, so if you have any advice,
warnings, or anything at all to say to us, please feel free! We'd like
to hear from all of you as much as possible.

In regard hosting, would suggest that all but a standard WSGI
interface be ignored for Python 3.0.

This is because it is extremely unlikely mod_python will ever be
ported to Python 3.0.

Although flup may be heading towards having Python 3.0 support, I
personally would suggest Django not support fastcgi directly as is
done now, even if it is just a wrapper around WSGI interface in flup.
Instead, push the adaption of WSGI to FASTCGI via flup onto the user.
In the long run this will reduce maintenance efforts as only have to
worry about one hosting interface type.

In respect of WSGI, very much suggest you use Apache/mod_wsgi as
reference to how WSGI interface should be implemented in Python 3.0.
Don't assume that whatever you get runserver to do under Python 3.0
will be correct. Only other WSGI server worth looking at this point is
the in development CherryPy WSGI server support for Python 3.0.

Graham

[Rajeev J Sebastian]

On Sun, Jan 10, 2010 at 10:20 AM, Graham Dumpleton

Post by Graham Dumpleton
Although flup may be heading towards having Python 3.0 support, I
personally would suggest Django not support fastcgi directly as is
done now, even if it is just a wrapper around WSGI interface in flup.
Instead, push the adaption of WSGI to FASTCGI via flup onto the user.
In the long run this will reduce maintenance efforts as only have to
worry about one hosting interface type.

Uh ... I really hope Django supports fastcgi directly via flup.

Regards
Rajeev J Sebastian

[Suno Ano]

Graham> In regard hosting, would suggest that all but a standard WSGI
Graham> interface be ignored for Python 3.0.

At first thought many might think about mod_wsgi use by Apache here.
However, I have come to the conclusion that
http://projects.unbit.it/uwsgi/ too is an excellent solution. Especially
when combined with Cherokee or nginx. Apache just is not *the solution*
for anything anymore.

- http://sunoano.name/ws/public_xhtml/python.html#wake_up_call


Graham> In respect of WSGI, very much suggest you use Apache/mod_wsgi
Graham> as reference to how WSGI interface should be implemented in
Graham> Python 3.0. Don't assume that whatever you get runserver to do
Graham> under Python 3.0 will be correct. Only other WSGI server worth
Graham> looking at this point is the in development CherryPy WSGI
Graham> server support for Python 3.0.

Here I disagree. There is http://projects.unbit.it/uwsgi/ which works
excellent with Cherokee and nginx for example. There is great support
amongst those solutions for Django already:

- http://www.cherokee-project.com/doc/cookbook_uwsgi.html
- http://www.cherokee-project.com/doc/cookbook_django.html

Apache/mod_wsgi should not be *the* reference solution as far as I am
concerned. It may be one solution amongst others (uWSGI with Cherokee
for example) to look at.

[Graham Dumpleton]

 Graham> In regard hosting, would suggest that all but a standard WSGI
 Graham> interface be ignored for Python 3.0.
At first thought many might think about mod_wsgi use by Apache here.
However, I have come to the conclusion thathttp://projects.unbit.it/uwsgi/too is an excellent solution. Especially
when combined with Cherokee or nginx. Apache just is not *the solution*
for anything anymore.
 -http://sunoano.name/ws/public_xhtml/python.html#wake_up_call
 Graham> In respect of WSGI, very much suggest you use Apache/mod_wsgi
 Graham> as reference to how WSGI interface should be implemented in
 Graham> Python 3.0. Don't assume that whatever you get runserver to do
 Graham> under Python 3.0 will be correct. Only other WSGI server worth
 Graham> looking at this point is the in development CherryPy WSGI
 Graham> server support for Python 3.0.
Here I disagree. There ishttp://projects.unbit.it/uwsgi/which works
excellent with Cherokee and nginx for example. There is great support
 -http://www.cherokee-project.com/doc/cookbook_uwsgi.html
 -http://www.cherokee-project.com/doc/cookbook_django.html
Apache/mod_wsgi should not be *the* reference solution as far as I am
concerned. It may be one solution amongst others (uWSGI with Cherokee
for example) to look at.

So, you would trust someone who from what I have seen has never once
participated in any discussions on the Python WEB-SIG in regard to
WSGI on Python 3.0 and in his own documentation somewhere suggests
that the uWSGI Python 3.0 support may need to be changed because it
may not actually match what proposals exist for WSGI on Python 3.0.

All I can say then is good luck, you will be on your own.

Graham

[Roberto De Ioris]

Post by Suno Ano
- http://www.cherokee-project.com/doc/cookbook_uwsgi.html
- http://www.cherokee-project.com/doc/cookbook_django.html
Apache/mod_wsgi should not be *the* reference solution as far as I am
concerned. It may be one solution amongst others (uWSGI with Cherokee
for example) to look at.

Hi Suno, glad to hear you are a happy uWSGI user, but you should really
not follow our python3.x implementation for a project like Django.
Our (current) implementation is based on our customers needs, it has
nothing to do with what will be decided (if ever) on WEB-SIG. We are
lurking at that list waiting for a decision. We are software bitches, we
really have no interest on forcing (or even 'suggesting') the world on
our implementations. We write what the world/customer wants :P

Seriuosly, you should look at Graham's mod_wsgi implementation if you
want something that very-very-probably will be a standard
implementation. uWSGI 0.9.5 (scheduled for february) will have a
mod_wsgi compatibility layer for python3.x so your choice on what way to
follow is very simple :)

[Eugene]

Hello everyone,

My name is Eugen Tamasdan and I am a member of the Python 3.0 porting
project at U of T. Looking forward to contribute to Django!

- Eugene

[Martin v. Löwis]

Post by Dave
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.

Hi Dave,

Please take a look at

http://wiki.python.org/moin/PortingDjangoTo3k

I have already done such a port, which I can update to the current
code base if there is interest. As others have discussed, this port
takes the approach of providing a single code base for both 2.x and
3.x
support, which is an approach that I would strongly recommend for
any kind of port of software to Python 3.x (unless dropping 2.x
support
altogether is acceptable).

Regards,
Martin

[Alex Gaynor]

Post by Russell Keith-Magee

Post by Dave
My name is Dave Weber, and I'm a student at the University of Toronto,
studying Computer Science. For one of our undergraduate courses led by
Greg Wilson (http://www.cs.utoronto.ca/~gvwilson/), myself and a group
of 10 other computer science students will be trying to port Django to
Python 3.

Hi Dave,
Please take a look at
http://wiki.python.org/moin/PortingDjangoTo3k
I have already done such a port, which I can update to the current
code base if there is interest. As others have discussed, this port
takes the approach of providing a single code base for both 2.x and
3.x
support, which is an approach that I would strongly recommend for
any kind of port of software to Python 3.x (unless dropping 2.x
support
altogether is acceptable).
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Martin, that page says Django is ported enough to run the tutorial,
have you tried running the test suite under your patch to see what the
results are?

Alex

[Martin v. Löwis]

Post by Alex Gaynor
Martin, that page says Django is ported enough to run the tutorial,
have you tried running the test suite under your patch to see what the
results are?

No, I haven't. It's been a while, but IIRC, the standard install would
not
install the test suite, so the test suite would not get converted to
3.x.
I started looking into converting the test suite, but then got
distracted
and never returned to the port.

Regards,
Martin

[Alex Gaynor]

Post by Martin v. Löwis

Post by Alex Gaynor
Martin, that page says Django is ported enough to run the tutorial,
have you tried running the test suite under your patch to see what the
results are?

No, I haven't. It's been a while, but IIRC, the standard install would
not
install the test suite, so the test suite would not get converted to
3.x.
I started looking into converting the test suite, but then got
distracted
and never returned to the port.
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Ok. As a suggestion to the student's looking at this getting the test
suite running should probably be your first priority :)

Alex

[Dave]

Getting the test suite running will definitely be a priority for us,
thanks for the advice on that. We're still a bit away from the coding
phase though, and we're still trying to get familiar with the source
code. One of the things that we're working on is an architecture
documentation, which we would like to ask for some feedback on our
approach for it. Based on our understanding of the source code, the
most appropriate breakdown we could think of was having the View,
HTTP, URL Dispatching and Web Server as one section, the Model as
another, and the Template as the final subsection. We have two people
working on the Model, another two on the View, HTTP, URL Dispatching
and Web Server, and one person on the Template.

Any thoughts on the breakdown and amount of people assigned to each
subsection?

Finally, Martin it's good to hear from you! We're looking at your work
with great interest; I'm sure we'll have more questions for you in the
near future.

Post by Martin v. Löwis

Post by Alex Gaynor
Martin, that page says Django is ported enough to run the tutorial,
have you tried running the test suite under your patch to see what the
results are?

No, I haven't. It's been a while, but IIRC, the standard install would
not
install the test suite, so the test suite would not get converted to
3.x.
I started looking into converting the test suite, but then got
distracted
and never returned to the port.
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

Ok.  As a suggestion to the student's looking at this getting the test
suite running should probably be your first priority :)
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Alex Gaynor]

Post by Dave
Getting the test suite running will definitely be a priority for us,
thanks for the advice on that. We're still a bit away from the coding
phase though, and we're still trying to get familiar with the source
code. One of the things that we're working on is an architecture
documentation, which we would like to ask for some feedback on our
approach for it. Based on our understanding of the source code, the
most appropriate breakdown we could think of was having the View,
HTTP, URL Dispatching and Web Server as one section, the Model as
another, and the Template as the final subsection. We have two people
working on the Model, another two on the View, HTTP, URL Dispatching
and Web Server, and one person on the Template.
Any thoughts on the breakdown and amount of people assigned to each
subsection?
Finally, Martin it's good to hear from you! We're looking at your work
with great interest; I'm sure we'll have more questions for you in the
near future.

Post by Martin v. Löwis

Post by Alex Gaynor
Martin, that page says Django is ported enough to run the tutorial,
have you tried running the test suite under your patch to see what the
results are?

No, I haven't. It's been a while, but IIRC, the standard install would
not
install the test suite, so the test suite would not get converted to
3.x.
I started looking into converting the test suite, but then got
distracted
and never returned to the port.
Regards,
Martin
--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group athttp://groups.google.com/group/django-developers?hl=en.

Ok.  As a suggestion to the student's looking at this getting the test
suite running should probably be your first priority :)
Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

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?

Alex

[Martin v. Löwis]

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). In Python 3, there is no automatic
conversion anymore between byte strings and Unicode strings, so 3.x
developers wouldn't expect Django to transparently encode/decode
(unless when interfacing with databases, networks, or files, of
course). OTOH, if this feature is widely used in applications,
continued support for it would certainly be feasible.

Martin

[Luke Plant]

Post by Martin v. Löwis

Post by Alex Gaynor
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).

Post by Alex Gaynor

Template(u"{{ foo }}").render(Context({"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Post by Alex Gaynor

Template("{{ foo }}").render(Context({u"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Post by Alex Gaynor

Template("{{ foo }}").render(Context({"foo":u"bar"}))

u'bar'

Post by Martin v. Löwis

Post by Alex Gaynor

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

[Dave]

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?

Post by Luke Plant

Post by Martin v. Löwis

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).

Template(u"{{ foo }}").render(Context({"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({u"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({"foo":u"bar"}))

u'bar'

Post by Martin v. Löwis

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/

[Alex Gaynor]

Post by Dave
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?

Post by Luke Plant

Post by Martin v. Löwis

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).

Template(u"{{ foo }}").render(Context({"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({u"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({"foo":u"bar"}))

u'bar'

Post by Martin v. Löwis

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.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

I don't see much point in trying to put a specific number on it. For
example, the ORM (which represents a LOT of the tests) will pretty
much all just work once you work out the syntactic and unicode issues.
I imagine by fixing those you'll go from 0% to 50% completion nearly
overnight. Further, you guys know whether you're working hard on it,
and if you don't reach your goals due to unforseen complications, or
due to laziness. I see little value in trying to evaluate yourselves
based on the % of passing tests (but now we're delving far into my
personal education philosophies :P). Regardless, I think picking a
specific number would be incredibly difficult, and that if you still
want one you should work for 3 weeks and then see where you are, and
what seems reasonable there.

Alex
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me

[Mathieu Leduc-Hamel]

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...

Post by Dave
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?

Post by Luke Plant

Post by Martin v. Löwis

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).

Template(u"{{ foo }}").render(Context({"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({u"foo":"bar"}))

u'bar'

Post by Martin v. Löwis

Template("{{ foo }}").render(Context({"foo":u"bar"}))

u'bar'

Post by Martin v. Löwis

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.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

[Martin v. Löwis]

Post by Luke Plant

Template(u"{{ foo }}").render(Context({"foo":"bar"}))

u'bar'

I get

py> Template("{{ foo }}").render(Context({b"foo":b"bar"}))
''

I think that's correct: the dictionary has no key "foo".
I'm also unsure what this has to do with UTF-8: isn't this the regular
default encoding (ASCII) that allows you to have Unicode and byte
strings compare equal?

What is the syntax for variable names (i.e. can you even have non-
ASCII characters in variable names)?

Post by Luke Plant

Template("{{ foo }}").render(Context({u"foo":"bar"}))

u'bar'

py> Template(b"{{ foo }}").render(Context({"foo":b"bar"}))
'bar'

Not sure why this happens - perhaps variable names get always
converted into strings?

Post by Luke Plant

Template("{{ foo }}").render(Context({"foo":u"bar"}))

u'bar'

py> Template(b"{{ foo }}").render(Context({b"foo":"bar"}))
''

Also notice that it never produces bytes in these cases. Again, I'm
unsure why this happens.

Post by Luke Plant

MyModel.objects.filter(my_attr="foo")

py> Choice.objects.filter(choice=b'geht so')
[<Choice: geht so>]

Post by Luke Plant

MyModel.objects.filter(my_attr=u"foo")

py> Choice.objects.filter(choice='geht so')
[<Choice: geht so>]

Post by Luke Plant

mymodel_instance.my_attr = "foo"
mymodel_instance.my_attr = u"foo"

c=Choice()
c.choice=b'fine'
c.choice='fine'

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 - inPython2.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 inPython3.0 (thanks in part, I believe, to your good self :-),
and also in at least some databases, this is not an academic issue.

Not sure what issue you see here. It's most likely difficult to map
such names into a relational database. Having a restriction that
requires field names to follow SQL syntax sounds reasonable to me.

As for __dict__ now containing Unicode strings - this already had a
number of consequences on the patch. My recommendation would be that
identifier-like things always get represented as (unicode) strings in
Django on 3k (or more generally, by the "standard" string type).

Post by Luke Plant
Also, inPython3.0, you can have models with non-ascii names, which
challenges some assumptions about things like the INSTALLED_APPS
setting.

Again, I don't see a need to support these. I doubt the ability to
create them would be the primary reason why people would switch to
Python 3...

Post by Luke Plant
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.

I think migration of existing applications is probably the biggest
challenge. For a new 3.x application, the guideline should be to use
the (unicode) string type throughout, and leave encodings entirely to
Django.

Regards,
Martin