I believe it's caused by this Python bug: ​http://bugs.python.org/issue1242657 which caused exceptions raised by __len__ to be silently swallowed. A traceback from when the exception is successfully raised:

shows how __len__ swallowing exceptions would cause this test failure.

Don't know that it is worth fixing (apparently you'll just get empty lists instead of exceptions in cases where this is hit) but figured it was at least worth reporting in case anyone else runs across it. (I didn't find any likely match in my tracker search.)

Oldest firstNewest firstThreaded

Show commentsShow property changes

Change History (14)

Argh! Another __len__-related problem. I'm beginning to really hate its error handling (although, to be fair, if you did something bad in __len__ in, say, Python 1.5, the wheels really fell off the wagon, so the current safe behaviour is probably preferable).

Python 2.3 is still that important, then? I know the answer was a resounding 'yes' when someone asked on one of the lists about 8 months ago...but that was 8 months ago. The problem only occurs on 2.3, not 2.4 or 2.5.

Looks like there's not really a lot we can do about this. Arranging to not do anything in __len__ that might cause an exception is something I tried to do months ago for other reasons and the performance effects were terrible. So penalising python 2.4 and 2.5 for what is primarily a diagnostic message in this case isn't really worth it. Django works correctly if you don't make an error in Python 2.3 and I can live with some erroneous cases perform differently than they do in 2.4 and 2.5.

I've adjusted the test suite to not fail on those tests in 2.3, but that's as far as I'm going to go here. Not entirely satisfying, but we're fighting Python bugs and the way list() and friends are implemented internally in Python.

Python 2.3 is still that important, then? I know the answer was a resounding 'yes' when someone asked on one of the lists about 8 months ago...but that was 8 months ago. The problem only occurs on 2.3, not 2.4 or 2.5.

Elaborating on Malcolm's comments: Yes, Django 1.0 will support Python 2.3 - for two reasons:

Supporting Python implementations other than CPython (i.e., Jython, PyPy) is on the list for v1.0. Keeping the code compatible with CPython 2.3 is the easiest way to maintain support for these platforms.

Thanks for the clarification. I asked mainly to make sure I wasn't wasting people's time reporting 2.3 problems; I thought it possible things had changed since the issue was raised on one of the lists more than six months ago, but I guess not. So, I'll keep testing on it and report problems as I find them (this and the other I opened recently are the only ones I hit on the current codebase).

FYI this Python behavior of swallowing exceptions raised by __len__ has returned in the current (Beta 2) 2.6 release. I haven't tracked down yet whether that is intentional or an oversight on Python's part.

FYI this Python behavior of swallowing exceptions raised by __len__ has returned in the current (Beta 2) 2.6 release. I haven't tracked down yet whether that is intentional or an oversight on Python's part.

Yes, the Python bug cited in the description has been re-opened for 2.6/3.1 (not sure why that's not 3.0, but the bug tracker has 3.1) but not fixed as of yet. Not sure at this point if Django should skip this test when running on 2.6 (as it does for 2.3) or leave things as-is in the hope that Python will re-fix bug #1242657 before 2.6 is actually released.

This behaviour isn't showstopper-critical. If that feature of Django stopped working, you wouldn't receive a particular error when you made a mistake. That means only people doing bad things will be harmed and they shouldn't be doing bad things in the first place. So I'm happy to just not run that test on Python 2.6, at least for now.

(In [8570]) Hid a few QuerySet regression tests from Python 2.6 due to a bug in the the
Python beta releases. Failures there mean that incorrect code won't raise an
error, but it's otherwise harmless (correct code still runs correctly).