Python 3 port - all tests now pass on 2.5.4, 2.6.2, 2.7.2 and 3.2.2 with the same codebase
Vinay Sajip
Python 2.5.4, 2.6.2, 2.7.2 and 3.2.2.
Python 2.5.4
=========
Ran 4490 tests in 513.699s
OK (skipped=91, expected failures=3)
Python 2.6.2
=========
Ran 4490 tests in 455.615s
OK (skipped=89, expected failures=3)
Python 2.7.2
=========
Ran 4475 tests in 379.923s
OK (skipped=90, expected failures=3)
Python 3.2.2
=========
Ran 4420 tests in 389.154s
OK (skipped=96, expected failures=2, unexpected successes=1)
The tested code incorporates the latest Django SVN trunk changes
(r17168) as well as Luke Plant's patch[3] to only get an exception
object when actually needed (I missed a couple of cases).
Regards,
Vinay Sajip
[1] https://bitbucket.org/vinay.sajip/django/
[2] https://gist.github.com/1412432
[3] http://groups.google.com/group/django-developers/msg/3f2dd22295ff1555
Anssi Kääriäinen
> Python 3.2.2
> =========
> Ran 4420 tests in 389.154s
>
> OK (skipped=96, expected failures=2, unexpected successes=1)
I am currently running the test suite using psycopg2 (2.4.0 onwards
support Python 3) and Python 3.2. I can report that there are at least
three things needing fixing:
Trivial mistake in django/db/backends/postgresql_psycopg2/
operations.py:
- return u('(%s)') % conn.join([sql, u('interval \')%s\'' %
mods])
+ return u('(%s)') % conn.join([sql, u('interval \'%s\'') %
mods])
(the closing parenthesis for u('interval \') is at wrong place)
A mistake in django/db/backends/util.py L154:
- hsh = hashlib.md5(name).hexdigest()[:hash_len]
+ hsh = hashlib.md5(bytes(name, encoding="UTF8")).hexdigest()
[:hash_len]
The fix is probably not correct.
And then as last thing:
File "/home/akaj/Django3/django/tests/django/db/backends/
postgresql_psycopg2/base.py", line 57, in execute
reraise(utils.IntegrityError, utils.IntegrityError(*tuple(e)),
sys.exc_info()[2])
TypeError: 'IntegrityError' object is not iterable
I don't know what to do to that.
Otherwise looking good, though it might be that there are more errors.
- Anssi
Vinay Sajip
> I am currently running the test suite using psycopg2 (2.4.0 onwards
> support Python 3) and Python 3.2. I can report that there are at least
> three things needing fixing:
Anssi, thanks for posting this feedback.
> A mistake in django/db/backends/util.py L154:
> - hsh = hashlib.md5(name).hexdigest()[:hash_len]
> + hsh = hashlib.md5(bytes(name, encoding="UTF8")).hexdigest()
> [:hash_len]
>
> The fix is probably not correct.
Try just b(name) instead of bytes(name, ...) and see if that works.
>
> And then as last thing:
> File "/home/akaj/Django3/django/tests/django/db/backends/
> postgresql_psycopg2/base.py", line 57, in execute
> reraise(utils.IntegrityError, utils.IntegrityError(*tuple(e)),
> sys.exc_info()[2])
> TypeError: 'IntegrityError' object is not iterable
>
> I don't know what to do to that.
Replace *tuple(e) with *e.args (5 occurrences) and see how that works.
Regards,
Vinay Sajip
Anssi Kääriäinen
> Try just b(name) instead of bytes(name, ...) and see if that works.
Fixed with just the b.
> > I don't know what to do to that.
>
> Replace *tuple(e) with *e.args (5 occurrences) and see how that works.
Fixed.
Now for the next problems:
In django/db/models/sql/where.py, L53:
if (hasattr(value, '__iter__') and hasattr(value, 'next')):
->
if (hasattr(value, '__iter__')
and (hasattr(value, 'next') or hasattr(value,
'__next__'))):
This comes with the comment:
# Consume any generators immediately, so that we can
determine
# emptiness and transform any non-empty values correctly.
Don't know if the above fix is correct.
There are still more errors, seems like they are related to unicode <-
> bytes problems, for example:
File "/home/akaj/Django3/django/tests/regressiontests/cache/
tests.py", line 270, in test_data_types
self.assertEqual(self.cache.get("stuff"), stuff)
File "/home/akaj/Django3/django/tests/django/core/cache/backends/
db.py", line 71, in get
return pickle.loads(base64.decodestring(value))
File "/usr/lib/python3.2/base64.py", line 367, in decodestring
return decodebytes(s)
File "/usr/lib/python3.2/base64.py", line 359, in decodebytes
raise TypeError("expected bytes, not %s" % s.__class__.__name__)
TypeError: expected bytes, not str
And:
Traceback (most recent call last):
File "/home/akaj/Django3/django/tests/regressiontests/queries/
tests.py", line 1516, in test_exists
self.assertTrue("id" not in connection.queries[-1]['sql'] and
"name" not in connection.queries[-1]['sql'])
TypeError: Type str doesn't support the buffer API
- Anssi
Vinay Sajip
Okay, thanks - I'll look at these. By the way, I tried to get a
PostgreSQL server set up on my system (9.1, as that's the default for
Ubuntu Oneiric) and started running the tests, but they are running
very very slowly. I've got a very simple settings.py that basically
just has the minimum database connectivity settings (the same for
'default' and 'other', just the database name, username and password
all set to 'djangotest'). Are there any other settings I need to set
for a reasonable performance? I assumed the tests would use
transactions by default, but I'm not sure if that's correct.
Regards,
Vinay Sajip
Anssi Kääriäinen
> Okay, thanks - I'll look at these. By the way, I tried to get a
> PostgreSQL server set up on my system (9.1, as that's the default for
> Ubuntu Oneiric) and started running the tests, but they are running
> very very slowly. I've got a very simple settings.py that basically
> just has the minimum database connectivity settings (the same for
> 'default' and 'other', just the database name, username and password
> all set to 'djangotest'). Are there any other settings I need to set
> for a reasonable performance? I assumed the tests would use
> transactions by default, but I'm not sure if that's correct.
There is one easy thing you can do for testing, set fsync to off in
postgresql.conf. The file is probably at /etc/postgresql/9.1/main/
postgresql.conf. Then restart the server and tests should be way
faster. Note that if your machine crashes, you will likely lose all
data. But as this is testing server that should not matter.
To speed up things, here are the tests that failed for me after the
fixes posted upthread:
- cache
- select_for_update
- queries
- admin_views
Although I ran out of patience, there might be more still.
Vinay Sajip
On Dec 5, 12:57 am, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> There is one easy thing you can do for testing, set fsync to off in
> postgresql.conf. The file is probably at /etc/postgresql/9.1/main/
> postgresql.conf. Then restart the server and tests should be way
> faster. Note that if your machine crashes, you will likely lose all
> data. But as this is testing server that should not matter.
I've already done the fsync = off, but it didn't make that much
difference :-(
> To speed up things, here are the tests that failed for me after the
> fixes posted upthread:
> - cache
> - select_for_update
> - queries
> - admin_views
>
> Although I ran out of patience, there might be more still.
Well, thanks for that feedback. I'll run these selectively and see
what's thrown up.
Regards,
Vinay Sajip
Jeremy Dunck
>
> On Dec 5, 12:57 am, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
>
>> There is one easy thing you can do for testing, set fsync to off in
>> postgresql.conf. The file is probably at /etc/postgresql/9.1/main/
>> postgresql.conf. Then restart the server and tests should be way
>> faster. Note that if your machine crashes, you will likely lose all
>> data. But as this is testing server that should not matter.
>
> I've already done the fsync = off, but it didn't make that much
> difference :-(
See also:
http://www.revsys.com/writings/postgresql-performance.html
Postgresql ships with some not-great default settings.
Vinay Sajip
On Dec 5, 1:16 am, Jeremy Dunck <jdu...@gmail.com> wrote:
>
> See also:http://www.revsys.com/writings/postgresql-performance.html
>
Thanks, I'll dig into that.
Regards,
Vinay Sajip
Florian Apolloner
On Monday, December 5, 2011 2:10:50 AM UTC+1, Vinay Sajip wrote:
I've already done the fsync = off, but it didn't make that muchdifference :-(
Vinay Sajip
>
> To speed up things, here are the tests that failed for me after the
> fixes posted upthread:
> - cache
> - select_for_update
> - queries
> - admin_views
>
I've eliminated many of the errors here, but a few remain, at least
some of which are related to the psycopg2 driver under Python 3 [e.g.
test_ticket10432 leads to a SQL query apparently legitimately
containing " IN ()", which the backend rejects as a syntax error]. I'm
running the full suite now, but I don't expect it to finish before the
end of the day :-(
Regards,
Vinay
Vinay Sajip
On Dec 5, 11:30 am, Florian Apolloner <f.apollo...@gmail.com> wrote:
>
> Use a tablespace which lies in a ram disk, you can't get any faster than
> that I/O wise ;)
I've seen posts telling how to do this, but I had hoped to avoid the
need for it ...
Regards,
Vinay Sajip
Anssi Kääriäinen
> I've eliminated many of the errors here, but a few remain, at least
> some of which are related to the psycopg2 driver under Python 3 [e.g.
> test_ticket10432 leads to a SQL query apparently legitimately
> containing " IN ()", which the backend rejects as a syntax error]. I'm
> running the full suite now, but I don't expect it to finish before the
> end of the day :-
The test_ticket10432 should not generate any query at all. The tests in
django/db/models/sql/where.py should ensure that in the case of empty
__in condition the query will not be executed at all (or that part of
the where condition is removed if it is possible for the query to return
rows if the __in=() executes to False).
The problem is that the test in where.py:
if hasattr(value, '__iter__') and hasattr(value, 'next')
isn't correct. It seems that in python3 the 'next' has been renamed to
'__next__' and thus the generator will not be consumed. My python3
knowledge is basically nonexistent, so it might be I am wrong here.
As for test running speed: how fast is it for you? For me, using an old
laptop, the speed is around 20-30 minutes (can't test for accurate speed
right now). So, if it is much slower, you have something strange in your
setup.
- Anssi
Vinay Sajip
On Dec 5, 12:14 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> On 12/05/2011 01:41 PM, Vinay Sajip wrote:
>
> The test_ticket10432 should not generate any query at all. The tests in
> django/db/models/sql/where.py should ensure that in the case of empty
> __in condition the query will not be executed at all (or that part of
> the where condition is removed if it is possible for the query to return
> rows if the __in=() executes to False).
>
> The problem is that the test in where.py:
> if hasattr(value, '__iter__') and hasattr(value, 'next')
> isn't correct. It seems that in python3 the 'next' has been renamed to
> '__next__' and thus the generator will not be consumed. My python3
> knowledge is basically nonexistent, so it might be I am wrong here.
Aargh, yes. You mentioned this earlier, but I missed correcting this
when I did the other fixes. I've dealt with it now [basically, py3
defines 'next_name' which is 'next' on 2.x and '__next__' on 3.x - I
just changed it to hasattr(value, next_name)].
> As for test running speed: how fast is it for you? For me, using an old
> laptop, the speed is around 20-30 minutes (can't test for accurate speed
> right now). So, if it is much slower, you have something strange in your
> setup.
I haven't yet run it to completion, but have just now set it up to
use /dev/shm as per Florian's suggestion (as well as having fsync =
off). Will report the total time once the tests have all run.
Regards,
Vinay Sajip
Vinay Sajip
On Dec 5, 12:14 pm, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote:
> As for test running speed: how fast is it for you? For me, using an old
> laptop, the speed is around 20-30 minutes (can't test for accurate speed
> right now). So, if it is much slower, you have something strange in your
> setup.
Well, the test has now completed:
Ran 4474 tests in 8869.701s
FAILED (failures=18, errors=12, skipped=71, expected failures=2,
unexpected successes=1)
Not too bad for a first complete pass. Over two and a half hours to
run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and
with fsync = off. All else set to default values. Time to investigate
Jeremy's link to Frank Wiles' post ...
Tests are running in a (64-bit) VM with 1GB RAM on a machine with 8GB
physical RAM.
Regards,
Vinay Sajip
Carl Meyer
Hash: SHA1
Hi Vinay,
On 12/05/2011 04:41 AM, Vinay Sajip wrote:
[snip]
> containing " IN ()", which the backend rejects as a syntax error]. I'm
> running the full suite now, but I don't expect it to finish before the
> end of the day :-(
That sounds orders of magnitude slower than running the tests under
Postgres here - and I haven't done any of the pg-config tweaking others
have mentioned (not even turning fsync off). Which leads me to think
that either there is some particularly unusual Postgres slowness on your
machine, or there's a major performance regression with the 3.x port and
Postgres (which, if it's that significant, would block merging the port).
Maybe if you run the tests in 2.x under Postgres, with trunk instead of
the 3.x-port, you could observe the comparative speed on your same machine?
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7c4AwACgkQ8W4rlRKtE2chPQCeNPuFvnqgAjDTlvNwPZmQArNN
5EYAoLRvkznDey6Y9fQ7lVwhrLGRq9u7
=BUc4
-----END PGP SIGNATURE-----
Carl Meyer
Hash: SHA1
On 12/05/2011 08:10 AM, Vinay Sajip wrote:
> Not too bad for a first complete pass. Over two and a half hours to
> run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and
> with fsync = off. All else set to default values. Time to investigate
> Jeremy's link to Frank Wiles' post ...
I think first investigating any difference in performance between trunk
and your py3k branch makes more sense than heading straight to more
Postgres performance tweaks.
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7c4wUACgkQ8W4rlRKtE2djswCfaf/NDuIyO5SRgMfmTG/JBUif
83gAn3xrbtwWrgEeBdsM9vgdPYCoSgIh
=fbQj
-----END PGP SIGNATURE-----
Joe & Anne Tennies
http://www.phoronix.com/scan.php?page=article&item=ubuntu_1110_xenkvm&num=7
I know, lies and benchmarks, but it's still a point of comparison from another person. The part I don't know how to compare is how transactions per second translates to the test suite as I assume there isn't 3000 simultaneous transactions while running the tests.
--
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
Anssi Kääriäinen
> > Not too bad for a first complete pass. Over two and a half hours to
> > run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and
> > with fsync = off. All else set to default values. Time to investigate
> > Jeremy's link to Frank Wiles' post ...
>
> I think first investigating any difference in performance between trunk
> and your py3k branch makes more sense than heading straight to more
> Postgres performance tweaks.
For me the tests do not feel any slower on Python3 than they do on
Python2. Taking a few assorted tests, other is Python2 and trunk HEAD,
other Python3 and py3k branch HEAD:
python3 ./runtests.py --settings=test_pgsql admin_views queries
transactions
Ran 362 tests in 175.297s
FAILED (errors=5, skipped=3, expected failures=1)
./runtests.py --settings=test_pgsql admin_views queries transactions
Ran 362 tests in 209.128s
OK (skipped=4, expected failures=1)
As can be seen, there is no reason to expect python3 to be slower. It
is actually faster in this little test is, but that is probably
because my machine happens to generate wildly varying benchmark
results (powersaving or something doing weird things behind the
scenes).
- Anssi
Vinay Sajip
On Dec 5, 3:15 pm, Carl Meyer <c...@oddbird.net> wrote:
> That sounds orders of magnitude slower than running the tests under
> Postgres here - and I haven't done any of the pg-config tweaking others
> have mentioned (not even turning fsync off). Which leads me to think
> that either there is some particularly unusual Postgres slowness on your
> machine, or there's a major performance regression with the 3.x port and
> Postgres (which, if it's that significant, would block merging the port).
Or maybe I was just frustrated at the slowness of the tests - they
finished in under 3 hours. Given that the sqlite tests don't feel
slow, I assumed the problem was in the postgresql configuration. So I
have removed postgresql 9.1 (in case that was a factor), installed
8.4, and will re-run the tests. As you suggested, it's a good idea to
run the tests on the trunk to confirm whether it's a postgres
configuration issue.
Another thing that's different, of course, is the psycopg2 driver for
3.x - I'm not sure if it would be expected to contribute to the
problem. I can of course run under 2.x, with the standard psycopg2
driver installed.
Anyway, I don't think we should worry too much about the performance
just yet, especially as Anssi is not apparently seeing the same kind
of slowdown. Others can confirm or refute whether this slowdown is
seen in their environments.
Regards,
Vinay Sajip
Jeremy Dunck
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/05/2011 08:10 AM, Vinay Sajip wrote:
>> Not too bad for a first complete pass. Over two and a half hours to
>> run, and that' s running from /dev/shm (IIUC effectively RAMdisk) and
>> with fsync = off. All else set to default values. Time to investigate
>> Jeremy's link to Frank Wiles' post ...
>
> I think first investigating any difference in performance between trunk
> and your py3k branch makes more sense than heading straight to more
> Postgres performance tweaks.
I agree.
Carl, to be clear, if py3 pg is slower, but py2 pg is still in line w/
baseline, would that block merge to trunk? It's quite possible the
problem lies in psycopg, but I think merging (with caveat emptor on
the py3/pg combination) would still be good.
Carl Meyer
Hash: SHA1
On 12/05/2011 11:56 AM, Jeremy Dunck wrote:
> Carl, to be clear, if py3 pg is slower, but py2 pg is still in line w/
> baseline, would that block merge to trunk? It's quite possible the
> problem lies in psycopg, but I think merging (with caveat emptor on
> the py3/pg combination) would still be good.
Yeah, I agree. If there's no regression on py2 with the branch (which
seems to be the case given Anssi's rough data), then slow py3 is
certainly better than no py3. Though if its really ten-fold-plus slower,
that would make py3/pg pretty much unusable, depending whether its
something that's particularly bad in the test suite or that would affect
typical code similarly. This is of course all uninformed hypothetical
speculation :-)
Carl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7dFnQACgkQ8W4rlRKtE2cKmQCeJWaMv8xQ+OERPYGl6bZ7tv8H
vzcAn3zz0W26OxpDCoPf+tF/oOY33gh5
=qR3p
-----END PGP SIGNATURE-----
Alex Gaynor
--
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.
It depends *why* it's slow. If it's slow as a consequence of all the bytes calls and extra encoding/decoding, yeah I'd say that's a blocker, because it'll never improve otherwise. On the other hand if it's slow because psycopg happens to be slow on py3k, well, that's someone else's problem then and I'm ok to merge it.
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
Vinay Sajip
On Dec 5, 7:08 pm, Alex Gaynor <alex.gay...@gmail.com> wrote:
> It depends *why* it's slow. If it's slow as a consequence of all the bytes
> calls and extra encoding/decoding, yeah I'd say that's a blocker, because
> it'll never improve otherwise. On the other hand if it's slow because
> psycopg happens to be slow on py3k, well, that's someone else's problem
> then and I'm ok to merge it.
I've just started a run on unported Django with my postgresql
configuration. No hard data yet, but it seems just as slow as the dots
get printed to the screen. I guess that might be good news for the
port, but we'll wait and see what the final time is ... just to give
an idea, I re-ran the test on the port, but without using RAMdisk for
the data (but still with fsync = off), that took around 3h 15 min ...
I've only got a GB of RAM, running in a VM, and have done no tuning
other than fsync = off, so data from other testers might be more
representative than my own.
Regards,
Vinay Sajip
Vinay Sajip
> It depends *why* it's slow. If it's slow as a consequence of all the bytes
> calls and extra encoding/decoding, yeah I'd say that's a blocker, because
> it'll never improve otherwise. On the other hand if it's slow because
> psycopg happens to be slow on py3k, well, that's someone else's problem
> then and I'm ok to merge it.
Further to my earlier post, I do now think it's my PostgreSQL
configuration. I aborted my test of unported Django running with
psycopg2 - it had run 1223 tests in 4871.121 seconds, which would mean
an average of 4 seconds per test! The full suite of 4475 or so tests
would then take almost five hours! I will try to test with psycopg2 on
another machine, but that might not be possible for a while, so I'll
have to rely on the good offices of others like Anssi for some more
timely results.
Regards,
Vinay Sajip
Ian Clelland
Vinay Sajip
> After a lot of troubleshooting, and fun installing Python3.2 under
> virtualenv (Vinay, I think I ran into the same issue as you here:https://github.com/pypa/virtualenv/issues/194), I almost have the complete
> test suite running under MacPorts Python 3.2.2.
That's good news about the state of the tests on MacPorts 3.2.2. I
hope Carl reads your mail about the virtualenv issue :-)
> While installing Vinay's port (cloned freshly this morning from Bitbucket),
> I had to edit four files, in order to get them to run under Python 3:
[snip]
> Did I miss a step here, or not see an error which should have been
> corrected earlier? Nobody else has commented about Python3 syntax errors,
> so I'm thinking it's my process.
No, I got those today, too - but not on earlier days, for many days. I
suspect that it's something to do with merging upstream changes into
my port, but I haven't pinned it down. I pushed my changes this
afternoon, so you could try pulling my changes and re-testing.
Regards,
Vinay Sajip
Ian Clelland
======================================================================ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)A template can be loaded from an egg----------------------------------------------------------------------Traceback (most recent call last):File "/Users/ian/Code/Frameworks/py3k_django/build/tests/regressiontests/templates/loaders.py", line 88, in test_existingcontents, template_name = egg_loader.load_template_source("y.html")File "/Users/ian/Code/Frameworks/py3k_django/3k/django/template/loaders/eggs.py", line 28, in load_template_sourceraise TemplateDoesNotExist(template_name)django.template.base.TemplateDoesNotExist: y.html----------------------------------------------------------------------
return (resource_string(app, pkg_name).decode(settings.FILE_CHARSET), 'egg:%s:%s' % (app, pkg_name))
(Pdb) import pkg_resources(Pdb) pkg_resources.__file__'/Users/ian/.virtualenvs/py3k_django/lib/python3.2/site-packages/distribute-0.6.21-py3.2.egg/pkg_resources.py'
resource_name = resource_string(app, pkg_name)if hasattr(resource_name, 'decode'):resource_name = resource_name.decode(settings.FILE_CHARSET)return (resource_name, 'egg:%s:%s' % (app, pkg_name))
Vinay Sajip
On Dec 6, 4:18 am, Ian Clelland <clell...@gmail.com> wrote:
> If I replace line 25 with this block:
>
> resource_name = resource_string(app, pkg_name)
> if hasattr(resource_name, 'decode'):
> resource_name = resource_name.decode(settings.FILE_CHARSET)
> return (resource_name, 'egg:%s:%s' % (app, pkg_name))
>
> then all (expected) tests pass.
Thanks very much for this fix, I have applied it and tested in a venv,
and can confirm your findings. I have pushed this to BitBucket. I have
installed a PIL Python 3 port and bugs in that are causing 1 failure
and 1 error; everything else passes.
Regards,
Vinay Sajip
Joe & Anne Tennies
Python3 port on python 3.2.1 w/ sqlite:
* Ran 4429 tests in 528.327s
* FAILED (errors=1, skipped=96, expected failures=2, unexpected successes=1) +
Python3 port on python 2.7.2 w/ sqlite:
* Ran 4490 tests in 487.212s
* OK (skipped=82, expected failures=3)
Django trunk (bitbucket mirror) on python 2.7.2 w/ sqlite:
* Ran 4495 tests in 472.527s
* OK (skipped=82, expected failures=3)
All versions were grabbed around 11pm CST on 5 December 2011. The numbers were grabbed with a generally unused computer except for the tests (mostly just me browsing the web while I get bored waiting for tests to finish running). These are all single runs while I "putz" on my computer. I wouldn't count them for exacting numbers, but they should be good for finding order of magnitude problems. All tests are run w/ a command like "PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_postgres" using the system packages from Fedora 16.
Also, I had pypy 1.6 (from yum) installed. It would not run either trunk or the port. Not sure of the problem.
+) ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)
A template can be loaded from an egg
----------------------------------------------------------------------
Traceback (most recent call last):
contents, template_name = egg_loader.load_template_source("y.html")
raise TemplateDoesNotExist(template_name)
django.template.base.TemplateDoesNotExist: y.html
PS: I too have a slow postgres even after I upped the shared_buffers and effective_cache_size while disabling fsync, and it is still pretty darn slow. (info from: http://www.revsys.com/writings/postgresql-performance.html) I'm testing w/ trunk to get a baseline w/ psycopg2. I'll admit I'm using a slow HDD, but I waited well over an hour.
When I get back from work, I'll try psycopg2 and MySQL again tonight.
Vinay Sajip
> PS: I too have a slow postgres even after I upped the shared_buffers and
> effective_cache_size while disabling fsync, and it is still pretty darn
> slow. (info from:http://www.revsys.com/writings/postgresql-performance.html)
> I'm testing w/ trunk to get a baseline w/ psycopg2. I'll admit I'm using a
> slow HDD, but I waited well over an hour.
>
> When I get back from work, I'll try psycopg2 and MySQL again tonight.
Thanks for that, and for the useful feedback on the sqlite runs, too.
Regards,
Vinay Sajip
Ian Clelland
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.
Without doing anything else, I installed pymysql, and made a few minimal modifications to use that module in the mysql backend, and fixed one Python3 incompatibility issue in db/backends/mysql/compiler.py.
Ran 4429 tests in 18128.079sFAILED (failures=11, errors=375, skipped=114, expected failures=2, unexpected successes=1)
======================================================================ERROR: testApprovePost (regressiontests.comment_tests.tests.moderation_view_tests.ApproveViewTests)POSTing the delete view should mark the comment as removed
----------------------------------------------------------------------Traceback (most recent call last):
File "/Users/ian/Code/Frameworks/py3k_django/build/tests/regressiontests/comment_tests/tests/moderation_view_tests.py", line 142, in testApprovePostself.client.login(username="normaluser", password="normaluser")File "/Users/ian/Code/Frameworks/py3k_django/3k/django/test/client.py", line 514, in loginlogin(request, user)File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/auth/__init__.py", line 73, in loginrequest.session.cycle_key()File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/sessions/backends/base.py", line 253, in cycle_keyself.delete(key)File "/Users/ian/Code/Frameworks/py3k_django/3k/django/contrib/sessions/backends/db.py", line 75, in deleteSession.objects.get(session_key=session_key).delete()File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/base.py", line 583, in deletecollector.delete()File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/deletion.py", line 61, in decoratedfunc(self, *args, **kwargs)File "/Users/ian/Code/Frameworks/py3k_django/3k/django/db/models/deletion.py", line 228, in deletesender=model, instance=obj, using=self.usingFile "/Users/ian/Code/Frameworks/py3k_django/3k/django/dispatch/dispatcher.py", line 174, in sendresponse = receiver(signal=self, sender=sender, **named)File "/Users/ian/Code/Frameworks/py3k_django/build/tests/modeltests/signals/tests.py", line 57, in pre_delete_test(instance, instance.id is None)AttributeError: 'Session' object has no attribute 'id'
Vinay Sajip
On Dec 6, 11:29 pm, Ian Clelland <clell...@gmail.com> wrote:
>
> Without doing anything else, I installed pymysql, and made a few minimal
> modifications to use that module in the mysql backend, and fixed one
> Python3 incompatibility issue in db/backends/mysql/compiler.py.
which was?
> First initial test run indicates that there's still some work to do :)
>
> Ran 4429 tests in 18128.079s
> FAILED (failures=11, errors=375, skipped=114, expected failures=2,
> unexpected successes=1)
>
> (yeah, that's 18k seconds, just a bit over 5 hours, but mysql has never
> been fast on OS X; something about the way it rolls back the database
> between tests)
I presume you've tried the advice given here:
http://www.stereoplex.com/blog/speeding-up-django-unit-test-runs-with-mysql
Regards,
Vinay Sajip
Ian Clelland
Joe & Anne Tennies
I thought I'd put in my timing numbers on my computer (F16 on a Phenom II x6):
Python3 port on python 3.2.1 w/ sqlite:
* Ran 4429 tests in 528.327s
* FAILED (errors=1, skipped=96, expected failures=2, unexpected successes=1) +
Python3 port on python 2.7.2 w/ sqlite:
* Ran 4490 tests in 487.212s
* OK (skipped=82, expected failures=3)
Django trunk (bitbucket mirror) on python 2.7.2 w/ sqlite:
* Ran 4495 tests in 472.527s
* OK (skipped=82, expected failures=3)
Python3 port on python 3.2.1 w/ psycopg2:
* Ran 4429 tests in 3102.890s
*FAILED (errors=3, skipped=75, expected failures=2, unexpected successes=1) ++
Python3 port on python 2.7.2 w/ psycopg2:
* Ran 4490 tests in 3086.170s
* OK (skipped=61, expected failures=3)
Django trunk (bitbucket mirror) on python 2.7.2 w/ psycopg2:
* Ran 4495 tests in 3316.408s
* OK (skipped=61, expected failures=3)
All versions were grabbed around 11pm CST on 5 December 2011. The numbers were grabbed with a generally unused computer except for the tests (mostly just me browsing the web while I get bored waiting for tests to finish running). These are all single runs while I "putz" on my computer. I wouldn't count them for exacting numbers, but they should be good for finding order of magnitude problems. All tests are run w/ a command like "PYTHONPATH=..:$PYTHONPATH python ./runtests.py --settings=test_postgres" using the system packages from Fedora 16.
Also, I had pypy 1.6 (from yum) installed. It would not run either trunk or the port. Not sure of the problem.
+) ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)File "/home/joe/Projects/django2-3/django/tests/regressiontests/templates/loaders.py", line 88, in test_existing
A template can be loaded from an egg
----------------------------------------------------------------------
Traceback (most recent call last):File "/home/joe/Projects/django2-3/django/django/template/loaders/eggs.py", line 28, in load_template_source
contents, template_name = egg_loader.load_template_source("y.html")
raise TemplateDoesNotExist(template_name)
django.template.base.TemplateDoesNotExist: y.html
++) ERROR: test_recentactions_without_content_type (regressiontests.admin_views.tests.AdminViewStringPrimaryKeyTest)
If a LogEntry is missing content_type it will not display it in span tag under the hyperlink.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 54, in execute
return self.cursor.execute(query, args)
psycopg2.ProgrammingError: function upper(bytea) does not exist
LINE 1: ...WHERE UPPER("django_content_type"."name"::text) = UPPER('\x4...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/joe/Projects/django2-3/django/tests/regressiontests/admin_views/tests.py", line 1261, in test_recentactions_without_content_type
logentry = LogEntry.objects.get(content_type__name__iexact=should_contain)
File "/home/joe/Projects/django2-3/django/django/db/models/manager.py", line 131, in get
return self.get_query_set().get(*args, **kwargs)
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 361, in get
num = len(clone)
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 86, in __len__
self._result_cache = list(self.iterator())
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 293, in iterator
for row in compiler.results_iter():
File "/home/joe/Projects/django2-3/django/django/db/models/sql/compiler.py", line 699, in results_iter
for rows in self.execute_sql(MULTI):
File "/home/joe/Projects/django2-3/django/django/db/models/sql/compiler.py", line 754, in execute_sql
cursor.execute(sql, params)
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 60, in execute
reraise(utils.DatabaseError, utils.DatabaseError(*e[1].args), e[2])
File "/home/joe/Projects/django2-3/django/django/utils/py3.py", line 167, in reraise
raise value.with_traceback(tb)
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 54, in execute
return self.cursor.execute(query, args)
django.db.utils.DatabaseError: function upper(bytea) does not exist
LINE 1: ...WHERE UPPER("django_content_type"."name"::text) = UPPER('\x4...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
======================================================================
ERROR: test_recentactions_without_content_type (regressiontests.admin_views.tests.AdminViewStringPrimaryKeyTest)
If a LogEntry is missing content_type it will not display it in span tag under the hyperlink.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 54, in execute
return self.cursor.execute(query, args)
psycopg2.InternalError: current transaction is aborted, commands ignored until end of transaction block
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/joe/Projects/django2-3/django/tests/regressiontests/admin_views/tests.py", line 1228, in tearDown
self.client.logout()
File "/home/joe/Projects/django2-3/django/django/test/client.py", line 544, in logout
session.delete(session_key=session_cookie.value)
File "/home/joe/Projects/django2-3/django/django/contrib/sessions/backends/db.py", line 75, in delete
Session.objects.get(session_key=session_key).delete()
File "/home/joe/Projects/django2-3/django/django/db/models/manager.py", line 131, in get
return self.get_query_set().get(*args, **kwargs)
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 361, in get
num = len(clone)
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 86, in __len__
self._result_cache = list(self.iterator())
File "/home/joe/Projects/django2-3/django/django/db/models/query.py", line 293, in iterator
for row in compiler.results_iter():
File "/home/joe/Projects/django2-3/django/django/db/models/sql/compiler.py", line 699, in results_iter
for rows in self.execute_sql(MULTI):
File "/home/joe/Projects/django2-3/django/django/db/models/sql/compiler.py", line 754, in execute_sql
cursor.execute(sql, params)
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 60, in execute
reraise(utils.DatabaseError, utils.DatabaseError(*e[1].args), e[2])
File "/home/joe/Projects/django2-3/django/django/utils/py3.py", line 167, in reraise
raise value.with_traceback(tb)
File "/home/joe/Projects/django2-3/django/django/db/backends/postgresql_psycopg2/base.py", line 54, in execute
return self.cursor.execute(query, args)
django.db.utils.DatabaseError: current transaction is aborted, commands ignored until end of transaction block
======================================================================
ERROR: test_existing (regressiontests.templates.loaders.EggLoaderTest)
A template can be loaded from an egg
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/joe/Projects/django2-3/django/tests/regressiontests/templates/loaders.py", line 88, in test_existing
contents, template_name = egg_loader.load_template_source("y.html")
File "/home/joe/Projects/django2-3/django/django/template/loaders/eggs.py", line 28, in load_template_source
raise TemplateDoesNotExist(template_name)
django.template.base.TemplateDoesNotExist: y.html
PS: I too have a slow postgres even after I upped the shared_buffers and effective_cache_size while disabling fsync, and it is still pretty darn slow. (info from: http://www.revsys.com/writings/postgresql-performance.html) I'm testing w/ trunk to get a baseline w/ psycopg2. I'll admit I'm using a slow HDD, but I waited well over an hour.
When I get back from work, I'll try psycopg2 and MySQL again tonight.
Joe & Anne Tennies
The attached patch fix makes the last 2 tests pass in both 2.7.2 and 3.2.1 under postgres and sqlite. I'll be honest and say I don't know why, so please figure out why and explain it to me. I think it's because psycopg2 won't run upper on something that's not a unicode in python 3, but it needs to be a bytestring later to have the "buffer interface" implemented.
Ian Clelland
>> >
>> > Without doing anything else, I installed pymysql, and made a few minimal
>> > modifications to use that module in the mysql backend, and fixed one
>> > Python3 incompatibility issue in db/backends/mysql/compiler.py.
>>
>> which was?
It was the use of None as the first argument to map(), which Python 2 accepts, and happily zips its remaining arguments, but Python 3 throws a TypeError (sensibly, as None is not a callable)
>>
>> > First initial test run indicates that there's still some work to do :)
>> >
>> > Ran 4429 tests in 18128.079s
>> > FAILED (failures=11, errors=375, skipped=114, expected failures=2,
>> > unexpected successes=1)
>> >
>> > (yeah, that's 18k seconds, just a bit over 5 hours, but mysql has never
>> > been fast on OS X; something about the way it rolls back the database
>> > between tests)
>>
>> I presume you've tried the advice given here:
>>
>> http://www.stereoplex.com/blog/speeding-up-django-unit-test-runs-with-mysql
>>
>
> I haven't yet, but that's where I remember reading why MySQL tests are always slow on the mac. Thanks for the pointer again, though -- hopefully it speeds up testing tonight.
Vinay Sajip
On Dec 7, 5:14 am, "Joe & Anne Tennies" <tenn...@gmail.com> wrote:
> So, I hg pull; hg update and reran the Python3 tests. The Egg import test
> passes now.
>
> The attached patch fix makes the last 2 tests pass in both 2.7.2 and 3.2.1
> under postgres and sqlite. I'll be honest and say I don't know why, so
> please figure out why and explain it to me. I think it's because psycopg2
> won't run upper on something that's not a unicode in python 3, but it needs
> to be a bytestring later to have the "buffer interface" implemented.
I think that part about "upper" is probably right - it doesn't make
sense to run "upper" on anything other than text.
Part of it is just bugs in my conversion - if you look at some of the
other test methods in the same test case, it appears that I applied
b() in some places when I shouldn't have.
Regards,
Vinay Sajip