In response to the call to test py2.x on django's current master, I ran the test suite for Votizen. Our codebase is currently running with django 1.4.x.
Our codebase is ~100kloc, ~32kloc of which is tests. We use abstract model inheritance a good bit, but no concrete inheritance. No i18n or multi-tz. In use: python2.6/2.7 python-memcache tastypie MySQLdb django-celery/celery django-imagekit django-classy-tags Results (so far): 1) Our custom test runner broke: we used to force DB connection feature detection (there was a bug in TEST_MIRROR'd feature detection) so we could do some juggling; forced detection is now gone and is implicit; this seems to remove the need to even do the underlying hack for us. 2) Revealed a DB alias which was missing a TEST_MIRROR declaration for us. It used to work, but we were wrong and just lucky. 3) tastypie broken by a const moving in the django tree; fixed in https://github.com/toastdriven/django-tastypie/commit/71a1f0a161a7f3d549bce9b07984212ee4a8c81a 4) after upgrading tastypie master (27d17b7db7afd6c81da24f64f5b4562b59134582), a bunch of failures like: ... return self.dispatch('list', request, **kwargs) vi +176 upvote/api/tastypie.py # dispatch response = self._dispatch(request_type, request, **kwargs) ... vi +172 upvote/api/tastypie.py # _dispatch request, **kwargs) vi +474 /Users/jdunck/.virtualenvs/votizen-1.5/lib/python2.7/site-packages/tastypie/resources.py # dispatch response = method(request, **kwargs) vi +1130 /Users/jdunck/.virtualenvs/votizen-1.5/lib/python2.7/site-packages/tastypie/resources.py # get_list paginator = self._meta.paginator_class(request.GET, sorted_objects, resource_uri=self.get_resource_uri(), limit=self._meta.limit, max_limit=self._meta.max_limit, collection_name=self._meta.collection_name) TypeError: get_resource_uri() takes exactly 2 arguments (1 given) -- it turns out our subclass .get_resource_uri *required* bundle_or_obj, while tastypie internally does bundle_or_obj=None. It happened to work on 0.9.11; switching ours to also be optional fixed. 5) We have some URLNode subclasses and as such had to have a compatibility layer for future.url and furture.URLNode moving to django.template. 6) We had some test failures where TransactionalTestCase.assertContains used to work (text was coerced by smart_str prior to d1452f60974da6f0e54ff9ad7a03d2c115675d10). While we could argue that only text vars should be passed to assert(Not)Contains, I think the removal of smart_str(text) here was likely unintentional. Post-py3ization, I think it should probably be put back as force_text(text, response._charset). I raised a ticket and made a related patch/pull req: https://code.djangoproject.com/ticket/18980 I have a couple remaining issues which I've run out of time to work through just now: upvote.api.tests.test_tastypie:VoterResourceTestCase.test_XXXXX ValueError: astimezone() cannot be applied to a naive datetime (tastypie master + dj 1.5?) upvote.candidates.tests.views.test_profile_home:CandidatesProfileTest.test_friends EmptyPage: That page contains no results (almost certainly an internal problem) And the last one, I hesitate to raise because it's likely to be specific to my machine, but... our (django-nose-based) test runner hangs after completing the suite but before tearing down. Using dtruss I can see it's hanging on select/kevent, and using gdb I see it's in _mysql_ConnectionObject_query. I'm unsure where to get debug symbols for either mac python or mysqldb (or at least, I haven't spent the time to get there). I mention it despite it seeming environment-specific because it's possibly hanging due to the unicode/py3 changes. I just don't know. #0 0x00007fff9867aaf2 in read () #1 0x00000001105fe8ba in vio_read () #2 0x000000011057fbb1 in my_real_read () #3 0x000000011057f778 in my_net_read () #4 0x0000000110572cb2 in cli_safe_read () #5 0x000000011057705d in cli_read_query_result () #6 0x000000011057608e in mysql_real_query () #7 0x0000000110563d14 in _mysql_ConnectionObject_query () #8 0x000000010f738d77 in PyEval_EvalFrameEx () -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
