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
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
The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
the same codebase:
--
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.
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
That would be very useful feedback, thanks.
Regards,
Vinay Sajip
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
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
> 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
The Python 3 port now has all tests passing on 2.7.2 and 3.2.2 with
the same codebase:
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/
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
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
> 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
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
* 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
itertools.izip_longest was added in Python 2.6, though, so a
compatibility function is needed for Python 2.5.
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
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.
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
By "library" I assume you're referring to PyMySQL. Is there a repo I
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.
can clone, so I can start testing with MySQL?
Great - thanks!
> I'm down to four failures and one error now -- I'll post back once those
> are done, with a set of patches, hopefully.
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.
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
Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be
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
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.
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/
>
> 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
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-----
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