2010/1/14 Jesus Mager <fon...@gmail.com>: > 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.
>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: >>> >>> 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 post to this group, send email to django-develop...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> django-developers+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/django-developers?hl=en. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers" group. >> To post to this group, send email to django-develop...@googlegroups.com. >> To unsubscribe from this group, send email to >> django-developers+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-developers?hl=en. >> >> >> >> > > > > -- > Jesus Mager > [www.h1n1-al.blogspot.com] > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-develop...@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > > > -- Łukasz Rekucki
-- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
