Python 3 port - all tests now pass on 2.7.2 and 3.2.2 with the same codebase

6,644 views
Skip to first unread message

Vinay Sajip

unread,
Dec 2, 2011, 10:55:51 AM12/2/11
to Django developers
The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
the same codebase:

Python 2.7.2
=========

Ran 4475 tests in 373.875s

OK (skipped=90, expected failures=3)

Python 3.2.2
=========

Ran 4420 tests in 364.044s

OK (skipped=97, expected failures=2, unexpected successes=1)

This incorporates the very latest changes in Django SVN trunk
(r17165).

Regards,

Vinay Sajip

Jannis Leidel

unread,
Dec 2, 2011, 12:59:58 PM12/2/11
to Django developers
Incredible, thanks!

Jacob Kaplan-Moss

unread,
Dec 2, 2011, 1:03:29 PM12/2/11
to django-d...@googlegroups.com
On Fri, Dec 2, 2011 at 9:55 AM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
> The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
> the same codebase:

WOOOO!

This is really fantastic news - I can't thank you enough for pushing
this. I've just started scratching the surface and don't have any
specific feedback yet, but I want to make sure you know how
appreciative I am.

I'll try to spend the weekend writing/porting an app or two. If I can,
I'll let you know how it goes.

Jacob

Håkon Erichsen

unread,
Dec 2, 2011, 1:11:06 PM12/2/11
to django-d...@googlegroups.com
2011/12/2 Vinay Sajip <vinay...@yahoo.co.uk>
The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
the same codebase:


Wohoo! Can't wait to try py3 with Django! :)


Regards,
Håkon Erichsen

Joe & Anne Tennies

unread,
Dec 2, 2011, 1:34:27 PM12/2/11
to django-d...@googlegroups.com
So, last time I saw, you had only run against sqlite. Do you need help testing it against postgres, MySQL, and oracle (perhaps some unofficial ones)? What about all the caching backends? Do we need tests Python 3 equivalent tests for the ones that were skipped due to being Python 2-isms? What about some sort of "porting guide" or other needed documentation?

Basically, what's left, besides getting it merged into the official trunk that people can help you with?

2011/12/2 Håkon Erichsen <hakon.e...@gmail.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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.



--
Joe & Anne Tennies
ten...@gmail.com

Tomek Paczkowski

unread,
Dec 2, 2011, 2:32:15 PM12/2/11
to django-d...@googlegroups.com
Most important: where to send all those beer pints?

Ricardo Bánffy

unread,
Dec 2, 2011, 2:55:42 PM12/2/11
to django-d...@googlegroups.com
Great news! \o/

Timothy.Broder

unread,
Dec 2, 2011, 3:46:35 PM12/2/11
to django-d...@googlegroups.com
awesome guys. big kudos

Ian Kelly

unread,
Dec 2, 2011, 4:29:15 PM12/2/11
to django-d...@googlegroups.com
On Fri, Dec 2, 2011 at 11:34 AM, Joe & Anne Tennies <ten...@gmail.com> wrote:
> So, last time I saw, you had only run against sqlite. Do you need help
> testing it against postgres, MySQL, and oracle (perhaps some unofficial
> ones)? What about all the caching backends? Do we need tests Python 3
> equivalent tests for the ones that were skipped due to being Python 2-isms?
> What about some sort of "porting guide" or other needed documentation?
>
> Basically, what's left, besides getting it merged into the official trunk
> that people can help you with?

I'm already planning to go through the Oracle tests this weekend to
get them ready for 1.4, so I'll run this through as well and let you
know how it goes. Right now I expect failures even in 2.7.

Cheers,
Ian

Vinay Sajip

unread,
Dec 2, 2011, 8:17:48 PM12/2/11
to Django developers
On Dec 2, 6:03 pm, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:
>
> I'll try to spend the weekend writing/porting an app or two. If I can,
> I'll let you know how it goes.

That would be very useful feedback, thanks.

Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 2, 2011, 8:23:11 PM12/2/11
to Django developers
On Dec 2, 6:34 pm, "Joe & Anne Tennies" <tenn...@gmail.com> wrote:
> So, last time I saw, you had only run against sqlite. Do you need help
> testing it against postgres, MySQL, and oracle (perhaps some unofficial
> ones)? What about all the caching backends? Do we need tests Python 3
> equivalent tests for the ones that were skipped due to being Python 2-isms?
> What about some sort of "porting guide" or other needed documentation?
>
> Basically, what's left, besides getting it merged into the official trunk
> that people can help you with?

Yes, you can help with one or all of the above items. As far as I
know, the additional tests that are skipped are because of
dependencies on PIL and setuptools (neither of which I have installed
to run with Python 3: and there are some PIL ports for Python3, plus
one can use distribute in place of setuptools. This is the area I am
working on currently - working in a virtualenv with distribute and a
PIL port installed.

You can certainly try helping with a PostgreSQL backend, I believe py-
postgresql can be used as a PostgreSQL driver under Python 3. Ian
Kelly mentioned on this thread that he'll be looking at the Oracle
backend.

Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 2, 2011, 8:27:33 PM12/2/11
to Django developers

On Dec 2, 7:32 pm, Tomek Paczkowski <to...@hauru.eu> wrote:
> Most important: where to send all those beer pints?

Heh. I do drink beer, but my liver would probably prefer it if someone
were to send me something from my Amazon wishlist, which is on

http://www.amazon.co.uk/registry/wishlist/2CJGJ3I4HEIK5

But don't all rush at once ;-)

Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 2, 2011, 8:29:21 PM12/2/11
to Django developers
On Dec 2, 9:29 pm, Ian Kelly <ian.g.ke...@gmail.com> wrote:

> I'm already planning to go through the Oracle tests this weekend to
> get them ready for 1.4, so I'll run this through as well and let you
> know how it goes.  Right now I expect failures even in 2.7.

Great, I look forward to the feedback. I can't do any testing at the
moment with an Oracle backend, unfortunately - but I can certainly
look at test failures under 3.x which succeed under 2.x to try and
eyeball fixes to problems.

Regards,

Vinay Sajip

adamrights

unread,
Dec 2, 2011, 8:41:38 PM12/2/11
to django-d...@googlegroups.com
If I get a little time this weekend I'll try this with a postgre backend. Awesome that this is being done and the Django looks to be more active.

Karen Tracey

unread,
Dec 3, 2011, 3:50:32 PM12/3/11
to django-d...@googlegroups.com
On Fri, Dec 2, 2011 at 10:55 AM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:
The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
the same codebase:

What about Pythons 2.5 and 2.6?

Karen

Luke Plant

unread,
Dec 3, 2011, 4:18:29 PM12/3/11
to django-d...@googlegroups.com
To follow up some discussion on reddit, the subject of exceptions was
brought up. The Python 2.X/3.X compatible way to do exceptions requires:

e = sys.exc_info()[1]

...if you need the actual exception object. As discussed on reddit, this
is slow on PyPy.

I did some checks in the py3k patch of all the cases where we actually
do this because we need the exception object. I found the following:

= Cases where slowness probably doesn't matter too much =

== Developer errors ==

- template syntax errors and other errors

- incorrect configuration e.g. import errors due to incorrect dotted
to path to some component

These are generally only observed during development, not production.

== Tests ==

- running tests - many instances at different levels of code - in
unittest and in tests themselves.

It would be nice if test suite ran fast, but not so important.

== Runtime 'exceptional' cases ==

- file handling errors e.g. file already exists, permission errors.
(These are likely 'rare' cases or misconfiguration, but conceivably
they could be common).

- general view exception handling.

If any exception happens in a view, (including Http404), we pass it
to the exception handling middleware. This also applies to
decorators created from middleware. (So, this might not be such an
'exceptional' case).

- crashers of various kinds, especially in management commands
e.g. can't serialize data in dumpdata command

- invalid HTTP requests

- some DB operational/integrity errors (the exception object is needed
to map between the different types of errors that should be raised)

- most of these were already calling sys.exc_info()

= Cases where slowness probably does matter =

- signals - errors are caught and appended to 'responses'. Signals
can be used for all kinds of things.

- wrapping DoesNotExist in IndexError in queryset slicing

- we could potentially change this behaviour - do we really
need to capture the underlying exception arguments and
pass to IndexError?

- Validation error handling - the validators in django.core.validators
for URLs and email validation use an actual exception object.

- model validation and form validation - use exceptions to pass info
around.

- errors that happen in templates but are silenced. (we check the
actual exception object to see if we should silence them). Since
they are silent, there could be any number of these going on in an
app.

- MultiJoin in query generation code - don't know how often this
is thrown and caught. We could conceivably change the way this works,
it is internal.

- Resolver404 errors - very common, since it is part of the URL
resolving mechanism. This is a documented API, so we can't change it.


I also found a couple of places where we can avoid creating the
exception object if `settings.DEBUG = False` - untested patch attached.

Regards,

Luke


--
The fashion wears out more apparel than the man.
-- William Shakespeare

Luke Plant || http://lukeplant.me.uk/

faster_404_exception_handling.diff

Vinay Sajip

unread,
Dec 3, 2011, 4:55:42 PM12/3/11
to Django developers
On Dec 3, 8:50 pm, Karen Tracey <kmtra...@gmail.com> wrote:

> On Fri, Dec 2, 2011 at 10:55 AM, Vinay Sajip <vinay_sa...@yahoo.co.uk>wrote:
>
> > The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
> > the same codebase:
>
> What about Pythons 2.5 and 2.6?

I've done nothing intentionally that prevents the port from working on
2.6 and 2.7 - it's just that my test machine happens to be a recent
Ubuntu variant that doesn't have them installed.

Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 3, 2011, 5:30:21 PM12/3/11
to Django developers

On Dec 3, 8:50 pm, Karen Tracey <kmtra...@gmail.com> wrote:

> What about Pythons 2.5 and 2.6?

I did a bit more checking, and a bit more work will be required on 2.5
and 2.6: for example, on 2.5, parse_qsl needs to come from elsewhere,
and on 2.6, unittest.skipIf needs to come from somewhere else. So some
changes need to be made to django/utils/py3.py to accommodate this -
it shouldn't be too much work, hopefully :-)

Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 3, 2011, 6:41:34 PM12/3/11
to Django developers
On Dec 3, 8:50 pm, Karen Tracey <kmtra...@gmail.com> wrote:

> What about Pythons 2.5 and 2.6?

Okay, I've now done some more testing, and with some minor changes, I
can report that good results were obtained on Pythons 2.5.4 and 2.6.2.
The remaining failures are representational ones - u'foo' vs. 'foo'
and order of dictionary keys in doctest output. Summaries follow.

Python 2.5.4
==========

Ran 4490 tests in 481.852s

FAILED (failures=1, skipped=91, expected failures=3)

Python 2.6.2
==========

Ran 4490 tests in 449.179s

OK (skipped=89, expected failures=3)


Regards,

Vinay Sajip

Vinay Sajip

unread,
Dec 4, 2011, 7:24:33 AM12/4/11
to Django developers

On Dec 3, 9:18 pm, Luke Plant <L.Plant...@cantab.net> wrote:
>
> I did some checks in the py3k patch of all the cases where we actually
> do this because we need the exception object. I found the following:
>

Thanks for the analysis and suggested patch. I've implemented this
patch in my branch, and the tests are running now on 2.5.4, 2.6.2,
2.7.2 and 3.2.2 :-)

Regards,

Vinay Sajip

Ian Kelly

unread,
Dec 6, 2011, 10:26:00 PM12/6/11
to django-d...@googlegroups.com
I've just finished going through the oracle tests and sent you a pull
request that fixes a few issues:

* compiler.py still had a map(None) call, that I replaced with izip_longest.
* cx_Oracle doesn't seem to want to accept bools as bind parameters
with Python 3; these had to be converted to ints.
* we were calling iterator.next() in one place instead of next(iterator)
* a couple of tests (one of which is specifically an Oracle test)
needed minor updates

The biggest change was just adding izip_longest to utils.py3 and
utils.itercompat.

With these changes, I'm not seeing any failures with oracle that I'm
not also seeing with sqlite3. I am seeing a bunch of failures,
though.

FAILED (failures=17, errors=24, skipped=97, expected failures=2,
unexpected successes=1)

Most of the failures are coming from the timezones tests.

Also, one rather obnoxious failure that I encountered was the
file_uploads.FileUploadTests.test_large_upload test, which doesn't
actually fail but just hangs indefinitely. I had to skip the test in
order to run the full suite.

Cheers,
Ian

Ian Clelland

unread,
Dec 6, 2011, 10:46:56 PM12/6/11
to django-d...@googlegroups.com

> * compiler.py still had a map(None) call, that I replaced with izip_longest.

>
> The biggest change was just adding izip_longest to utils.py3 and
> utils.itercompat.


I had the same issue with MySQL -- I used a block like this:

try:
   from itertools import zip_longest
except ImportError:
   # python 2.x
   from itertools import izip_longest as zip_longest

The code doesn't really seem to mind; iterator or generator, so I didn't think it was worth making an exact compatibility function


> Ian

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

--
Regards,
Ian Clelland
<clel...@gmail.com>

Ian Kelly

unread,
Dec 6, 2011, 11:25:14 PM12/6/11
to django-d...@googlegroups.com
On Tue, Dec 6, 2011 at 8:46 PM, Ian Clelland <clel...@gmail.com> wrote:
>
>> * compiler.py still had a map(None) call, that I replaced with
>> izip_longest.
>
>>
>> The biggest change was just adding izip_longest to utils.py3 and
>> utils.itercompat.
>
>
> I had the same issue with MySQL -- I used a block like this:
>
> try:
>    from itertools import zip_longest
> except ImportError:
>    # python 2.x
>    from itertools import izip_longest as zip_longest
>
> The code doesn't really seem to mind; iterator or generator, so I didn't
> think it was worth making an exact compatibility function

itertools.izip_longest was added in Python 2.6, though, so a
compatibility function is needed for Python 2.5.

Ian Clelland

unread,
Dec 7, 2011, 12:53:37 AM12/7/11
to django-d...@googlegroups.com


On Tuesday, December 6, 2011, Ian Kelly <ian.g...@gmail.com> wrote:
> itertools.izip_longest was added in Python 2.6, though, so a
> compatibility function is needed for Python 2.5.

Ahh, that's a good catch. I'll have to make use of your solution, then.

Ian

Vinay Sajip

unread,
Dec 7, 2011, 7:14:59 AM12/7/11
to Django developers
On Dec 7, 5:53 am, Ian Clelland <clell...@gmail.com> wrote:

> On Tuesday, December 6, 2011, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> > itertools.izip_longest was added in Python 2.6, though, so a
> > compatibility function is needed for Python 2.5.
>
> Ahh, that's a good catch. I'll have to make use of your solution, then.
>

I've already pulled Ian Kelly's changes from his BitBucket repo. Which
MySQL driver are you using for Python 3? I started looking at

git://github.com/davispuh/MySQL-for-Python-3.git

but it appears to expect queries formatted with {} rather than %s, so
it doesn't seem that I can use it.

Regards,

Vinay Sajip

Ian Clelland

unread,
Dec 7, 2011, 10:50:12 AM12/7/11
to django-d...@googlegroups.com
I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a drop-in replacement for MySQLdb. The biggest change is in the data converters -- they have a different function signature from MySQLdb's.

I have had to make a couple of patches to the library, which I hope to get applied upstream, otherwise it's working pretty well, so far.

I'm down to four failures and one error now -- I'll post back once those are done, with a set of patches, hopefully.

Ian
 

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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Vinay Sajip

unread,
Dec 7, 2011, 10:55:07 AM12/7/11
to Django developers

On Dec 7, 3:50 pm, Ian Clelland <clell...@gmail.com> wrote:
> I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
> drop-in replacement for MySQLdb. The biggest change is in the data
> converters -- they have a different function signature from MySQLdb's.
>
> I have had to make a couple of patches to the library, which I hope to get
> applied upstream, otherwise it's working pretty well, so far.

By "library" I assume you're referring to PyMySQL. Is there a repo I
can clone, so I can start testing with MySQL?

> I'm down to four failures and one error now -- I'll post back once those
> are done, with a set of patches, hopefully.

Great - thanks!

Regards,

Vinay Sajip

Ian Clelland

unread,
Dec 7, 2011, 11:16:55 AM12/7/11
to django-d...@googlegroups.com
On Wed, Dec 7, 2011 at 7:55 AM, Vinay Sajip <vinay...@yahoo.co.uk> wrote:

On Dec 7, 3:50 pm, Ian Clelland <clell...@gmail.com> wrote:
> I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
> drop-in replacement for MySQLdb. The biggest change is in the data
> converters -- they have a different function signature from MySQLdb's.
>
> I have had to make a couple of patches to the library, which I hope to get
> applied upstream, otherwise it's working pretty well, so far.

By "library" I assume you're referring to PyMySQL. Is there a repo I
can clone, so I can start testing with MySQL?

There is now :)


It needs some supporting code in backends/mysql/base.py -- I'll start another discussion thread for those issues. (i.e. Do we support pymysql in the mysql backend, or do we create a mysql_pymysql, akin to postgres_psycopg2?) 

> I'm down to four failures and one error now -- I'll post back once those
> are done, with a set of patches, hopefully.

Great - thanks!

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-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.

Ian Clelland

unread,
Dec 7, 2011, 6:53:39 PM12/7/11
to django-d...@googlegroups.com
Just finished a full suite test, with the PyMySQL adapter, and I'm down to 5 failures and 2 errors:

Gory details:

Ian Clelland

unread,
Dec 8, 2011, 10:52:48 AM12/8/11
to django-d...@googlegroups.com
Update:

As of last night, between Vinay's patches, some of my own, and some MySQL configuration tweaks, I think I have all (expected) tests passing with the PyMySQL adapter. I still need to run one more complete pass through the test suite to be sure that I haven't introduced any regressions, but it's looking pretty good.

I also managed to compile Vinay's clone of the MySQLdb driver for python 3, and with just one extra patch, it looks like all tests are passing with that code as well!

Ram Rachum

unread,
Dec 9, 2011, 3:26:17 PM12/9/11
to django-d...@googlegroups.com
In which Django release are we hoping to release this port? 1.4 or 1.5?


Ram.

Joseph Tennies

unread,
Dec 9, 2011, 7:21:50 PM12/9/11
to django-d...@googlegroups.com
I must say that I would personally LOVE to see this in 1.4 as some sort of "preview" (akin to __future__) to give people a chance to get their packages up and running on Python 3. This would also allow people to document the porting process properly.

Obviously, this is dependent on the code passing 



-- Sent from my Palm Pixi


On Dec 9, 2011 2:26 PM, Ram Rachum <ram.r...@gmail.com> wrote:

In which Django release are we hoping to release this port? 1.4 or 1.5?


Ram.

--
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/-/Y8-2tS9lth4J.

Paul Egges

unread,
Dec 9, 2011, 7:32:57 PM12/9/11
to django-d...@googlegroups.com
I was thinking the same thing. Make absolutely sure it works under 2.5-2.7 and even if there are a couple of issues or items not fully tested under 3.2.2 at least we will be moving in the right direction.

paul

Joe & Anne Tennies

unread,
Dec 9, 2011, 8:25:40 PM12/9/11
to django-d...@googlegroups.com
Doh, accidentally hit "send on my phone." Let me finish my thought:


I must say that I would personally LOVE to see this in 1.4 as some sort of "preview" (akin to __future__) to give people a chance to get their packages up and running on Python 3. This would also allow people to document the porting process properly.

Obviously, this is dependent on the code passing code reviews in time, which may be hard as I know this effort is based upon a separate effort.  I'm betting this ends up being a lot of code that will need some very specific people's time. I know Jannis would like the original person to review the additional changes.

Core Developers, what else would we need as far as documentation? I'm assuming the current test suite should be good. Do we need some more numbers besides Linux and maybe OS X to prove timing still looks good? Would there be a potentially larger slow down w/ all the u() and b() calls on Windows than the others?

I have no governing power on the project, so these are all my opinion with no power to make them happen.




On Dec 9, 2011 2:26 PM, Ram Rachum <ram.r...@gmail.com> wrote:

In which Django release are we hoping to release this port? 1.4 or 1.5?


Ram.
--
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/-/Y8-2tS9lth4J.
To post to this group, send email to django-d...@googlegroups.com.
To unsubscribe from this group, send email to django-develop...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.




--

Gert Van Gool

unread,
Dec 10, 2011, 7:40:52 AM12/10/11
to django-d...@googlegroups.com
What I would love as a developer in the documentation is, what do I
need to do so my code "could" run on Python 3.
It might not work, but most obvious issues (like b() and u()) would be
out of the way.

-- Gert

Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be

Vinay Sajip

unread,
Dec 10, 2011, 9:22:26 AM12/10/11
to Django developers

On Dec 10, 12:40 pm, Gert Van Gool <gertvang...@gmail.com> wrote:
> What I would love as a developer in the documentation is, what do I
> need to do so my code "could" run on Python 3.
> It might not work, but most obvious issues (like b() and u()) would be
> out of the way.

I know it's not the official documentation, but you might find my
notes on the Wiki helpful:

https://code.djangoproject.com/wiki/PortingNotesFor2To3

Regards,

Vinay Sajip

Ian Clelland

unread,
Dec 10, 2011, 9:51:23 AM12/10/11
to django-d...@googlegroups.com


On Fri, Dec 9, 2011 at 4:32 PM, Paul Egges <mounta...@gmail.com> wrote:
I was thinking the same thing. Make absolutely sure it works under 2.5-2.7 and even if there are a couple of issues or items not fully tested under 3.2.2 at least we will be moving in the right direction.


My laptop just finished a run of tests overnight --

The branch passes the complete test suite now for me, under Python 2.5.6, 2.6.7, 2.7.2, and 3.2.2, with the sqlite, MySQLdb, and psycopg2 backends.

(Sorry, no Oracle here.)

Luke Plant

unread,
Dec 10, 2011, 11:47:37 AM12/10/11
to django-d...@googlegroups.com
On 09/12/11 20:26, Ram Rachum wrote:
> In which Django release are we hoping to release this port? 1.4 or 1.5?

1.4 is never going to happen. We are hoping to release a 1.4 alpha very
soon, merging this work would be a major mistake at this point.

The patch requires lots of changes to the way things work. Many are
small, but they impose some mental overhead (like using b() etc). We
need *all* the core developers to get fully up to speed with these
before we commit, otherwise we will introduce tons of bugs as we try to
get 1.4 out of the door, even if all the tests pass at the moment.

The timing is very good for 1.5, however, so hopefully we can merge soon
after the release of 1.4. Even then, I think 1.5 would be a "Python 3
preview" i.e. we wouldn't promise the same level of support for Python 3
as for Python 2.X.

Regards,

Luke

--
Environmentalists are much too concerned with planet earth. Their
geocentric attitude prevents them from seeing the greater picture
-- lots of planets are much worse off than earth is.

Luke Plant || http://lukeplant.me.uk/

Vinay Sajip

unread,
Dec 10, 2011, 12:09:38 PM12/10/11
to Django developers

On Dec 10, 4:47 pm, Luke Plant <L.Plant...@cantab.net> wrote:

>
> 1.4 is never going to happen. We are hoping to release a 1.4 alpha very
> soon, merging this work would be a major mistake at this point.
>
> The patch requires lots of changes to the way things work. Many are
> small, but they impose some mental overhead (like using b() etc). We
> need *all* the core developers to get fully up to speed with these
> before we commit, otherwise we will introduce tons of bugs as we try to
> get 1.4 out of the door, even if all the tests pass at the moment.
>
> The timing is very good for 1.5, however, so hopefully we can merge soon
> after the release of 1.4. Even then, I think 1.5 would be a "Python 3
> preview" i.e. we wouldn't promise the same level of support for Python 3
> as for Python 2.X.

Sounds like a plan :-)

Regards,

Vinay Sajip

Joe & Anne Tennies

unread,
Dec 10, 2011, 5:35:36 PM12/10/11
to django-d...@googlegroups.com
So, with the current plan to add 3.x support to 1.5 and the plan to remove 2.5.x support in 1.5. Should all the exception handling blocks be converted to "except MyExceptionClass as e:" style notation then? This also removes the need for u() and b(), right? This is because 2.6.x supports u' ' and b' '. Wait... it looks like u() would have to stick around for python 3, but b() could go away (at least w/ 2.7 as I don't have 2.6).

What should be the plan? Should one go back and remove support in Django for 2.5.x and below format (which is ugly, especially for something like exceptions) or keep the current approach of wrapping everything?

Carl Meyer

unread,
Dec 10, 2011, 6:03:56 PM12/10/11
to django-d...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/10/2011 03:35 PM, Joe & Anne Tennies wrote:
> So, with the current plan to add 3.x support to 1.5 and the plan to
> remove 2.5.x support in 1.5. Should all the exception handling blocks be
> converted to "except MyExceptionClass as e:" style notation then?

Seems to me the plan to drop Python 2.5 support after Django 1.4, and
merge Python 3 support then, is pretty solidly confirmed. In which case
there's no use keeping around 2.5 hacks in the Python 3 branch. So I'd
say yes, for sure.

Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk7j5VwACgkQ8W4rlRKtE2es3ACeJojvDcQ4G4FE6elvizdHmfIe
Le0An2LLMgRd6d0uAdy4/PjYpMWvZD+N
=qd4x
-----END PGP SIGNATURE-----

Kok Hoor (gmail)

unread,
Dec 10, 2011, 9:38:41 PM12/10/11
to django-d...@googlegroups.com, django-d...@googlegroups.com
I would like to say congrats and thanks to all those who have put in hard work on the Python 3 port. It is a very socially responsible thing to do, as django is one of the major open-source python framework, and will certainly act as encouragement for other python-based open-source to do the same (not to mention shut the mouth of critics who never stop mentioning django is still on python 2 when 3 is already out ages ago)

I personally know python via Google AppEngine, but never feel compelled to actually sacrifice my years of java / javascript knowledge to learn a new language! However django convinced me otherwise (love the 'for perfectionists with deadline' tagline!), and I believe a django on Python 3 will make a lot of difference.

Thanks guys and again, congrats for hard work done. Can't wait for django 1.5 in python 3!

Regards,
Kok Hoor

Sent from my iPad

Reply all
Reply to author
Forward
0 new messages