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.
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 ...
On Fri, Jan 8, 2010 at 8:25 PM, Dave <weber...@gmail.com> wrote: > 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 post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en.
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
On Jan 8, 11:25 am, Dave <weber...@gmail.com> wrote:
> 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.
On Sat, Jan 9, 2010 at 2:25 AM, Dave <weber...@gmail.com> wrote: > 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 :-)
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
On Jan 8, 1:25 pm, Dave <weber...@gmail.com> wrote:
> 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.
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.
2010/1/8 Russell Keith-Magee <freakboy3...@gmail.com>:
> On Sat, Jan 9, 2010 at 2:25 AM, Dave <weber...@gmail.com> wrote: >> 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. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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.
On Sun, Jan 10, 2010 at 10:20 AM, Graham Dumpleton
<graham.dumple...@gmail.com> wrote: > 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.
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.
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:
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> 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.
> 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 > amongst those solutions for Django already:
> 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.
> 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 :)
> On Sat, Jan 9, 2010 at 2:25 AM, Dave <weber...@gmail.com> wrote: > > 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?
<joshua.part...@gmail.com> wrote: > On Jan 9, 1:02 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote: >> On Sat, Jan 9, 2010 at 2:25 AM, Dave <weber...@gmail.com> wrote: >> > 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?
> -- > 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@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > 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
-- "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
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.
On Jan 12, 2010 11:53 PM, "Joshua Partogi" <joshua.part...@gmail.com> wrote:
On Jan 9, 1:02 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> On Sat, Jan 9, 2010 at 2:25 AM, Dave <weber...@gmail.com> wrote: > > Hello
everyone, > > > My name... Russ,
Would it be possible if the django core developers to create a python3 branch in the django svn repository?
-- 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@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com<django-developers%2Bunsubscr ibe@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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.
On Wed, Jan 13, 2010 at 5:21 PM, Hanne Moa <hanne....@gmail.com> wrote: > 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: >> 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.
On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote: > 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: > > 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 in late 2008:
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.
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
On Jan 13, 7:22 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote: > > 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: > > > 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 > in late 2008:
> 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.
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.
On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey <kmtra...@gmail.com> wrote: > On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote:
>> 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: >> > 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 > in late 2008:
> 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 post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en.
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
> On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey <kmtra...@gmail.com> wrote: >> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote:
>>> 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: >>> > 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 >> in late 2008:
>> 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 post to this group, send email to django-developers@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscribe@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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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.
>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).
> 2010/1/13 Josh Roesslein <jroessl...@gmail.com>: >> 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
>> On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey <kmtra...@gmail.com> wrote: >>> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa <hanne....@gmail.com> wrote:
>>>> 2010/1/13 Tobias McNulty <tob...@caktusgroup.com>: >>>> > 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 >>> in late 2008:
>>> 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 post to this group, send email to django-developers@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-developers+unsubscribe@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-developers@googlegroups.com. >> To unsubscribe from this group, send email to django-developers+unsubscribe@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-developers@googlegroups.com. > To unsubscribe from this group, send email to django-developers+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
> 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.
On Thu, Jan 14, 2010 at 1:43 PM, Jesus Mager <fon...@gmail.com> wrote: > 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:
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.
On Thu, Jan 14, 2010 at 2:17 PM, Marty Alchin <gulop...@gmail.com> wrote: > 2010/1/14 Łukasz Rekucki <lreku...@gmail.com>: > > 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.
On Wed, Jan 13, 2010 at 9:51 AM, Josh Roesslein <jroessl...@gmail.com>wrote:
> 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?
