Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 28, 7:14 pm, Vinay Sajip  wrote:

> suite is a boon in this regard. Though having worked through the
> tests, it doesn't seem like the DRY principle is followed as much as
> it could be ... for example, the same literals being used over and
> over again in copy/paste fashion, requiring patches in multiple
> locations to add u() and b() wrappers, for example. I didn't have time
> to rationalise this, as I was focused more on identifying and fixing
> failures and errors.

Ironically, I notice that I repeated myself in using "for example"
twice in the above paragraph ;-)

Regards,

Vinay Sajip

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 28, 5:36 pm, Jannis Leidel  wrote:
>
> Ah, that makes sense, in fact your approach is much closer to what I
> remember doing when pip and virtualenv was ported.

Right, since I did those ports originally :-)

> Honestly, I'm not sure how hard the merge is, as I'm not sure how much
> changed. Martin could probably shed some light on it how he wants to deal
> with it (e.g. svnmerge.py or not).

Sure.

> Fair enough, I just realized that's a discussion we need to have in a
> separate thread (~"What's the best approach for migrating Django projects
> from 2.X to3.X?") that can be handled later in the porting process. When
> in doubt I would rather use a module like six that has community traction
> than writing our own though.

There are areas where the current code needs to do metaclass-based
checks, and that involves delving into the specifics of the
implementation of with_metaclass. This being the case, I made a
modified version of Benjamin's which uses "_DjangoBase" as the
intermediate parent class. IMO we need this to distinguish from other
classes implemented using with_metaclass from the official six
package.

> Personally I'm fine with it, but as you say, it requires discipline
> (I broke pip more than once). But it's definitely something that needs
> some input from the other core devs, and probably a very good
> documentation of the dos and don'ts.

Having good code coverage helps to spot these potential breakages well
before a release (or even a checkin), and Django's extensive test
suite is a boon in this regard. Though having worked through the
tests, it doesn't seem like the DRY principle is followed as much as
it could be ... for example, the same literals being used over and
over again in copy/paste fashion, requiring patches in multiple
locations to add u() and b() wrappers, for example. I didn't have time
to rationalise this, as I was focused more on identifying and fixing
failures and errors.

Regards,

Vinay Sajip

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Jannis Leidel]

On 28.11.2011, at 18:08, Vinay Sajip wrote:

> On Nov 28, 1:04 pm, Jannis Leidel  wrote:
>> 
>> I'm a bit concerned that you didn't get in touch with us before you
>> started with the work, since tracking the changes would have been
>> easier. FWIW, Martin von Löwis, Alex and me would be those you can
>> ask if you need any further help, usually also on IRC in #django-dev.
> 
> Well, it's only been about a week of elapsed time. I always start
> these sort of ports on an experimental-and-potentially-throwaway
> basis, and I didn't know until I started how things would progress -
> and well, once I was into it, I was just dipping in and out amidst
> doing other things, so I suppose I just focused on the task at hand
> rather than the big picture.

I see, that's absolutely fine, and to be honest, getting so much
progress done is definitely a good problem to have :)

>> Have you worked on top of the current py3k branch in SVN (which should
>> be mirrored in the Mercurial repo)? Also, did you get in touch with
>> Martin von Löwis who has previously spearheaded the porting efforts
>> for a while and has been granted commit privileges to the py3k branch?
> 
> Yes, I used the BitBucket repo and the features/py3k branch within
> that. I didn't contact Martin directly about this, as my approach is a
> little different to what he had started, in that Martin's approach is
> based on running 2to3 on the code to get new 3-friendly code, whereas
> my approach is to have a single codebase with runs on 2.x and 3.x.
> It's more than a small philosophical difference - I value the
> information that 2to3 gives, but it just acts as the driver for
> porting "by hand" with my standard development tools.

Ah, that makes sense, in fact your approach is much closer to what I
remember doing when pip and virtualenv was ported. In that sense, I'm
definitely fine with that. How much of that approach needs to be
documented for end users is probably something we can deal with later.

>> I'm asking simply because I'm wondering how we should get your changes
>> reviewed and committed to the official repo, it's a bit like facing a
>> done deal.
> 
> Well, I undertook the approach you mentioned in the "Python 3 and you"
> thread back in September, which was to look at the features/py3k
> branch and focus on test failures. Of course I didn't use the py3ktest
> script (which involves the 2to3 pass), running just plain runtests.py
> instead. And it's only been a little over a week, so it can't be that
> hard to merge the changes assuming you agree with the approach. Even
> if you start over, it's still less than a person-week of effort,
> right?

Honestly, I'm not sure how hard the merge is, as I'm not sure how much
changed. Martin could probably shed some light on it how he wants to deal
with it (e.g. svnmerge.py or not).

>> Aha, meaning that you've copied over parts of the six module? Would you
>> (also as a way for helping out Django users later to port their code)
>> recommend putting six completely in Django? We've previously done that
>> with other libraries, e.g. unittest2.
> 
> I have no strong views on using six directly as a dependency, and I've
> only used small parts of it (with_metaclass, reraise) directly. It's
> certainly not needed as a dependency - you can see that the
> django.utils.py3 module (which provides the functionality needed by
> Django) is pretty small.

Fair enough, I just realized that's a discussion we need to have in a
separate thread (~"What's the best approach for migrating Django projects
from 2.X to 3.X?") that can be handled later in the porting process. When
in doubt I would rather use a module like six that has community traction
than writing our own though.

>> Indeed they are, so the next step is to review them bit by bit and align
>> it with the work done before your work. Ideally committing it to SVN.
> 
> Right, and I can provide some help with that (other work permitting).
> Possibly some work could be done to look at merging the default branch
> with the features/py3k branch, as a first step - presumably default
> tracks SVN trunk closely. The main thing is to see whether you are
> comfortable with the single codebase approach (requires some small
> additional discipline from developers to consider str/bytes issues
> carefully, do imports from utils.py3 where appropriate, etc. - nothing
> too onerous).

Personally I'm fine with it, but as you say, it requires discipline
(I broke pip more than once). But it's definitely something that needs
some input from the other core devs, and probably a very good
documentation of the dos and don'ts.

> Carl Meyer may be able to chime in with his experience
> re. pip/virtualenv, which were ported using the same approach a while
> ago, and have seen maintenance work and new releases since then. Also
> it's worth looking at the way metaclasses have been done in the port
> and to see if you can identify any issues. A lot of the changes are
> 

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 28, 9:29 am, Kiril Vladimirov  wrote:
> My point was the social factor. I mean the GitHub community is quite
> bigger. It's not big issue if we're using mercurial instead of git. Sure, I
> prefer git, it's faster and stuff, but it's not a big deal, right now.

Well, it's not as if there's a big team required, and presumably
interested parties who can contribute will be subscribed to this list
anyway. There probably isn't the kind of need for a lot of back-and-
forth, given that the overall approach and some specific
implementation decisions are acceptable to the core devs.

> Anyway, I'm trying to get into making the tests run and if I see some
> result from my work, will try to figure out some sync between github and
> bitbucket.

Great, we'd like to see what you find.

Regards,

Vinay Sajip

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 28, 1:04 pm, Jannis Leidel  wrote:
>
> I'm a bit concerned that you didn't get in touch with us before you
> started with the work, since tracking the changes would have been
> easier. FWIW, Martin von Löwis, Alex and me would be those you can
> ask if you need any further help, usually also on IRC in #django-dev.
>

Well, it's only been about a week of elapsed time. I always start
these sort of ports on an experimental-and-potentially-throwaway
basis, and I didn't know until I started how things would progress -
and well, once I was into it, I was just dipping in and out amidst
doing other things, so I suppose I just focused on the task at hand
rather than the big picture.

> Have you worked on top of the current py3k branch in SVN (which should
> be mirrored in the Mercurial repo)? Also, did you get in touch with
> Martin von Löwis who has previously spearheaded the porting efforts
> for a while and has been granted commit privileges to the py3k branch?

Yes, I used the BitBucket repo and the features/py3k branch within
that. I didn't contact Martin directly about this, as my approach is a
little different to what he had started, in that Martin's approach is
based on running 2to3 on the code to get new 3-friendly code, whereas
my approach is to have a single codebase with runs on 2.x and 3.x.
It's more than a small philosophical difference - I value the
information that 2to3 gives, but it just acts as the driver for
porting "by hand" with my standard development tools.

> I'm asking simply because I'm wondering how we should get your changes
> reviewed and committed to the official repo, it's a bit like facing a
> done deal.

Well, I undertook the approach you mentioned in the "Python 3 and you"
thread back in September, which was to look at the features/py3k
branch and focus on test failures. Of course I didn't use the py3ktest
script (which involves the 2to3 pass), running just plain runtests.py
instead. And it's only been a little over a week, so it can't be that
hard to merge the changes assuming you agree with the approach. Even
if you start over, it's still less than a person-week of effort,
right?

> Aha, meaning that you've copied over parts of the six module? Would you
> (also as a way for helping out Django users later to port their code)
> recommend putting six completely in Django? We've previously done that
> with other libraries, e.g. unittest2.

I have no strong views on using six directly as a dependency, and I've
only used small parts of it (with_metaclass, reraise) directly. It's
certainly not needed as a dependency - you can see that the
django.utils.py3 module (which provides the functionality needed by
Django) is pretty small.

> Yeah, we've talked about that and don't consider 3.0 or 3.1 to be sensible to
> support in the future (given obvious bugs and/or lack of support from Python 
> core).

Good, that rhymes with my thinking on it :-)

> Indeed they are, so the next step is to review them bit by bit and align
> it with the work done before your work. Ideally committing it to SVN.

Right, and I can provide some help with that (other work permitting).
Possibly some work could be done to look at merging the default branch
with the features/py3k branch, as a first step - presumably default
tracks SVN trunk closely. The main thing is to see whether you are
comfortable with the single codebase approach (requires some small
additional discipline from developers to consider str/bytes issues
carefully, do imports from utils.py3 where appropriate, etc. - nothing
too onerous). Carl Meyer may be able to chime in with his experience
re. pip/virtualenv, which were ported using the same approach a while
ago, and have seen maintenance work and new releases since then. Also
it's worth looking at the way metaclasses have been done in the port
and to see if you can identify any issues. A lot of the changes are
pretty mechanical, wrapping literals with u() and b() - nothing too
contentious there. Escape character handling esp. in regexes is
another area where closer inspection would be worthwhile. The test
codebase contained a lot of Unicode literals (i.e. Unicode literals in
the source code, which would have been encoded in UTF-8 in the files
actually stored on disk) and I have converted these to use Unicode
escapes, as this is more portable.

Regards,

Vinay Sajip

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Jannis Leidel]

Hi Vinay,

Many thanks for your efforts so far, as you can imagine I have a few
questions, both procedural and technical. I should note though that
I haven't reviewed all your changes in detail yet, since they are..
massive :)

I'm a bit concerned that you didn't get in touch with us before you
started with the work, since tracking the changes would have been
easier. FWIW, Martin von Löwis, Alex and me would be those you can
ask if you need any further help, usually also on IRC in #django-dev.

On 25.11.2011, at 18:33, Vinay Sajip wrote:

> I'm working on a port of Django to Python 3. I'm getting close, and in
> terms of
> test coverage pretty much almost there, but a few remaining test
> failures are
> eluding me, and I could probably use some help to speed things up.
> 
> I started with the features/py3k branch on the BitBucket Django mirror
> (the one
> at https://bitbucket.org/django/django), but whereas that was
> approaching from
> a point of view of running 2to3 over the Django codebase, I've
> followed my
> preferred strategy of aiming for a single codebase for 2.x and 3.x.
> (This
> strategy worked well for the virtualenv and pip ports which I did a
> while ago.)

Have you worked on top of the current py3k branch in SVN (which should
be mirrored in the Mercurial repo)? Also, did you get in touch with
Martin von Löwis who has previously spearheaded the porting efforts
for a while and has been granted commit privileges to the py3k branch?

I'm asking simply because I'm wondering how we should get your changes
reviewed and committed to the official repo, it's a bit like facing a
done deal.

> I've updated the django.utils.py3 module to add whatever I needed,
> gratefully
> borrowing ideas from Benjamin Peterson's six project as needed.

Aha, meaning that you've copied over parts of the six module? Would you
(also as a way for helping out Django users later to port their code)
recommend putting six completely in Django? We've previously done that
with other libraries, e.g. unittest2.

> I run the standard test suite on the codebase using Python 2.7.2 and 3.2.2 
> (I'm
> not supporting 3.0 or 3.1 - 3.2 is stable, 'callable' came back and is 
> liberally
> used in Django, and I'm not sure it's worth bothering with support for 
> 3.0/3.1.

Yeah, we've talked about that and don't consider 3.0 or 3.1 to be sensible to
support in the future (given obvious bugs and/or lack of support from Python 
core).

> The branch is available at
> 
> https://bitbucket.org/vinay.sajip/django (features/py3k branch)
> 
> Latest test result summaries are as follows:
> 
> 2.7.2: ran 4229 tests in 301.690s
> OK (skipped=71, expected failures=3)
> 
> 3.2.2: Ran 4174 tests in 303.619s
> FAILED (failures=6, errors=2, skipped=78, expected failures=2,
>   unexpected successes=1)
> 
> I think these results are encouraging, and I hope you agree! I added 7
> skips, mostly these are due to different representations on 2.x and 3.x e.g.
> u'foo' vs. 'foo'.

Indeed they are, so the next step is to review them bit by bit and align
it with the work done before your work. Ideally committing it to SVN.

Jannis

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Russell Keith-Magee]

On Sat, Nov 26, 2011 at 1:33 AM, Vinay Sajip  wrote:
> I'm working on a port of Django to Python 3. I'm getting close, and in
> terms of
> test coverage pretty much almost there, but a few remaining test
> failures are
> eluding me, and I could probably use some help to speed things up.

Hi Vinay,

This is awesome work! Getting down to less than a dozen test failures
is amazing progress.

I don't have anything specific to add beyond that; I just wanted to
let you know the core team (or, at least, this member of the core
team) has seen your work, and is really encouraged that people are
making serious inroads into making Django on Py3 a reality.

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Kiril Vladimirov]

My point was the social factor. I mean the GitHub community is quite 
bigger. It's not big issue if we're using mercurial instead of git. Sure, I 
prefer git, it's faster and stuff, but it's not a big deal, right now. 

Anyway, I'm trying to get into making the tests run and if I see some 
result from my work, will try to figure out some sync between github and 
bitbucket.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/RJymGD-0e68J.
To post to this group, send email to django-developers@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.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Sindre Sorhus]

BitBucket has full git support btw.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Ax7zncVO2FYJ.
To post to this group, send email to django-developers@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.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

On Nov 27, 2:10 pm, Kiril Vladimirov  wrote:
> Have you made some sort of TODO list I could use?
> Or selecting some failing test and make it run fine would be fine as well?

I would say: just clone the repo, try to reproduce the results, report
any differences you find from my results, and select any failing test
to fix.

Another area to look at is to exercise other database backends, e.g.
PostgreSQL. I've only looked at sqlite as the obvious backend to use
first.

> Also, how about moving this project to GitHub?
> Django is there, too(https://github.com/django/) and I thing we could find
> more participants.

It just so happened that I found the BitBucket mirror first and used
that, but I wouldn't expect a serious developer, who wants to pitch
in, to object to using Mercurial and BitBucket instead. There's very
little to choose between them (BitBucket/GitHub), compared to the real
work still to be done in getting Django production-ready on 3.x.

Regards,

Vinay Sajip

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

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Kiril Vladimirov]

Have you made some sort of TODO list I could use? 
Or selecting some failing test and make it run fine would be fine as well?

Also, how about moving this project to GitHub? 
Django is there, too(https://github.com/django/) and I thing we could find 
more participants.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/wTlyOMg5dYkJ.
To post to this group, send email to django-developers@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.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[hiveNzin0]

Hi,

I'm just learning python at the moment to use Django so I don't have the 
knowledge to help you but keep up the good work.

I'm looking forward to seeing the result of your work.

Cheers. :)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/Sy0bpiSC-XgJ.
To post to this group, send email to django-developers@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.

Re: I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

Sorry the formatting of the post got mangled - not sure what happened
there!

Regards,

Vinay Sajip

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

I've made good progress in porting Django to Python 3, and could use some help!

[Vinay Sajip]

I'm working on a port of Django to Python 3. I'm getting close, and in
terms of
test coverage pretty much almost there, but a few remaining test
failures are
eluding me, and I could probably use some help to speed things up.

I started with the features/py3k branch on the BitBucket Django mirror
(the one
at https://bitbucket.org/django/django), but whereas that was
approaching from
a point of view of running 2to3 over the Django codebase, I've
followed my
preferred strategy of aiming for a single codebase for 2.x and 3.x.
(This
strategy worked well for the virtualenv and pip ports which I did a
while ago.)

I've updated the django.utils.py3 module to add whatever I needed,
gratefully
borrowing ideas from Benjamin Peterson's six project as needed. I run
the
standard test suite on the codebase using Python 2.7.2 and 3.2.2 (I'm
not
supporting 3.0 or 3.1 - 3.2 is stable, 'callable' came back and is
liberally
used in Django, and I'm not sure it's worth bothering with support for
3.0/3.1.

The branch is available at

https://bitbucket.org/vinay.sajip/django (features/py3k branch)

Latest test result summaries are as follows:

2.7.2: ran 4229 tests in 301.690s
OK (skipped=71, expected failures=3)

3.2.2: Ran 4174 tests in 303.619s
FAILED (failures=6, errors=2, skipped=78, expected failures=2,
unexpected successes=1)

I think these results are encouraging, and I hope you agree! I added 7
skips,
mostly these are due to different representations on 2.x and 3.x e.g.
u'foo'
vs. 'foo'.

I'm posting the summary results to

https://gist.github.com/1373553

The verbose listings are too big to post together to Github, giving me
an
"Entity Too Large" error. So these are posted separately to

https://gist.github.com/1393994 (2.7.2)

and

https://gist.github.com/1394000 (3.2.2).

The failures are:

ERROR: test_bad_404_template
(regressiontests.test_client_regress.models.TemplateExceptionTests)
I think this is due to Django trying to handle an unaught exception
and failing
to find the 4500.html template, because the test has set the templates
path to a
bad value (deliberately, for the purpose of the test).

ERROR: test_cull
(regressiontests.cache.tests.DBCacheTests)
This raises a "sqlite3.IntegrityError: datatype mismatch" but I
haven't yet
found the underlying cause.

FAIL: test_modelform_factory_metaclass
(regressiontests.model_forms_regress.tests.CustomMetaclassTestCase)
This is down to the way metaclasses are implemented slightly
differently.

FAIL: test_lazy_objects
(regressiontests.i18n.tests.TranslationTests)
Proxy object comparison code differs between 2.x and 3.x, needs
looking at.

FAIL: test_RegexValidator_raises_error_23
(modeltests.validators.tests.TestSimpleValidators)
I haven't tracked this down yet.

FAIL: testParsing
(regressiontests.conditional_processing.models.ETagProcessing)
This is down to different representations on 2.x and 3.x:
e\"t\"ag vs. e"t"ag

FAIL: test_null_display_for_field
(regressiontests.admin_util.tests.UtilTests)
This is also down to proxy comparison logic.

FAIL: test_templates
(regressiontests.templates.tests.Templates)
This is down to representational differences between 2.x and 3.x.

I did the work and ran the tests on a VM running Ubuntu Oneiric Ocelot
(x64).
You can hopefully reproduce these by cloning my repository, updating
to the
features/py3k branch, and then running one of

PYTHONPATH=.. python2.7 -u runtests.py --settings test_sqlite

or

PYTHONPATH=.. python3.2 -u runtests.py --settings test_sqlite

in the tests directory. The work's taken about a week of elapsed time
(on and
off), and I haven't tracked any changes in the default branch since
then.

Of course, I realise there's still a lot left to do, but I hope I have
broken
the back of it. I've approached it just from the point of trying to
get the
tests to pass, and not (yet) focused on actually running realistic
scenarios.
Perhaps some of my fixes need changing - having other devs' eyeballs
on the
code can definitely help.

Please let me have your comments!

Regards,

Vinay Sajip

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

Re: Porting Django to Python 3

[Martin v . Löwis]

> Some examples:

Thanks for posting them:

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

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

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

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

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

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

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

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

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

> 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

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

Re: Porting Django to Python 3

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Porting Django to Python 3

[Martin v . Löwis]

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

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

Re: Porting Django to Python 3

[Łukasz Rekucki]

2010/1/14 Marty Alchin :
> On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey  wrote:
>> 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.

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

>
> -Gul
>

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

Re: Porting Django to Python 3

[Marty Alchin]

On Thu, Jan 14, 2010 at 2:32 PM, Karen Tracey  wrote:
> 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
-- 
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.

Re: Porting Django to Python 3

[Karen Tracey]

On Thu, Jan 14, 2010 at 2:17 PM, Marty Alchin  wrote:

> 2010/1/14 Ł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
-- 

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.

Re: Porting Django to Python 3

[Marty Alchin]

2010/1/14 Ł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
-- 
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.

Re: Porting Django to Python 3

[Łukasz Rekucki]

2010/1/14 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.

>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 :
>> 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  wrote:
>>> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:

 2010/1/13 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
>>> 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 

Re: Porting Django to Python 3

[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

On Wed, Jan 13, 2010 at 8:22 AM, Karen Tracey  wrote:
> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:
>>
>> 2010/1/13 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
> 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.

Re: Porting Django to Python 3

[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


On Jan 13, 7:22 am, Karen Tracey  wrote:
> On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:
> > 2010/1/13 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
> 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.

Re: Porting Django to Python 3

[Karen Tracey]

On Wed, Jan 13, 2010 at 4:21 AM, Hanne Moa  wrote:

> 2010/1/13 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
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.

Re: Porting Django to Python 3

[Russell Keith-Magee]

On Wed, Jan 13, 2010 at 5:21 PM, Hanne Moa  wrote:
> 2010/1/13 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 %-)
-- 
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.

Re: Porting Django to Python 3

[Hanne Moa]

2010/1/13 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
-- 
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.

Re: Porting Django to Python 3

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

On Jan 12, 2010 11:53 PM, "Joshua Partogi"  wrote:

On Jan 9, 1:02 pm, Russell Keith-Magee  wrote:

> On Sat, Jan 9, 2010 at 2:25 AM, Dave  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?

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

Re: Porting Django to Python 3

[Alex Gaynor]

On Tue, Jan 12, 2010 at 10:52 PM, Joshua Partogi
 wrote:
> On Jan 9, 1:02 pm, Russell Keith-Magee  wrote:
>> On Sat, Jan 9, 2010 at 2:25 AM, Dave  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?
>
> 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-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.
>
>
>
>

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

Re: Porting Django to Python 3

[Joshua Partogi]

On Jan 9, 1:02 pm, Russell Keith-Magee  wrote:
> On Sat, Jan 9, 2010 at 2:25 AM, Dave  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?

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

Re: Porting Django to Python 3

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

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

Re: Porting Django to Python 3

[Russell Keith-Magee]

On Sat, Jan 9, 2010 at 2:25 AM, Dave  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-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.

Re: Porting Django to Python 3

[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

On Jan 8, 11:25 am, Dave  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-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.

Re: Porting Django to Python 3

[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


On Fri, Jan 8, 2010 at 8:25 PM, Dave  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-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.

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