Code

Opened 7 years ago

Closed 6 years ago

Last modified 6 years ago

#6332 closed (wontfix)

2 test failing for python trunk builds

Reported by: Matthew Flanagan <mattimustang@…> Owned by: nobody
Component: Testing framework Version: master
Severity: Keywords:
Cc: Triage Stage: Someday/Maybe
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Hi,

The following 2 tests fail on the python trunk (2.6) community buildbot http://www.python.org/dev/buildbot/community/all/?show=sparc%20Solaris%2010%20trunk

======================================================================
ERROR: Test that creation short-circuits to reuse existing references
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/django/tests/regressiontests/dispatch/tests/test_saferef.py", line 54, in testShortCircuit
    sd[s] = 1
TypeError: unhashable type: 'BoundMethodWeakref'

======================================================================
FAIL: Request a page that is known to throw an error
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/django/tests/modeltests/test_client/models.py", line 368, in test_view_with_exception
    self.assertRaises(KeyError, self.client.get, "/test_client/broken_view/")
AssertionError: KeyError not raised

Attachments (0)

Change History (3)

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Someday/Maybe

For anybody looking at this: these aren't necessarily our bugs, but we should keep an eye on them. Keep in mind that python 2.6 is still alpha.

Something that suddenly isn't raising a KeyError (the second case) looks like a change in the API, so worth tracking down to see if it's a Python core bug. The other case requires looking into the signal dispatching code and working out why the class suddenly became unhashable to see where the problem lies.

comment:2 Changed 6 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

Closing as wontfix (although it's not really the most valid resolution). This has been superseded by Karen Tracey's checking of our test suite on Python 2.6b2 and reporting bugs there as she goes along. We're at the point where tracking individual failures and addressing them is now necessary, since the goal is to support Python 2.6 in the 1.0 release.

comment:3 Changed 6 years ago by Karen Tracey <kmtracey@…>

I was not aware of this ticket (nor that buildbot, which will be a good thing for me to watch now).

The "unhashable type" error is on my list of things to delve into more deeply when I get time, though it no longer appears in 2.6b2 (it did in 2.6b1). I believe the relevant Python issue is here: http://bugs.python.org/issue2235. From the discussion it sounds like we may have some latent brokenness in Django, in that we have at least one class (django.db.models.Field) that implements __cmp__ without also explicitly implementing __hash__. The inherited __hash__ might not be doing the right thing.

Not sure what the KeyError not raised problem was since I haven't seen it in my testing and it's no longer happening on that buildbot.

Most of the errors on the buildbot are ones I have seen (you can find ones that require Django changes to fix by searching trac for python26 keyword). There are a couple (file names too long, ordering errors) that I haven't seen in my tests so I will see if I can understand what's different about the buildbot when I get a chance.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.