[py-dev] Re: [SQLObject] Re: Bug trying to access foreignKey objects for inherited tables. Patch for test attached

[holger krekel]

On Thu, Aug 25, 2005 at 11:32 -0500, Ian Bicking wrote:
> Oleg Broytmann wrote:
> >Hello! I've returned.
> >
> >On Thu, Aug 18, 2005 at 12:23:55PM -0300, Evandro Vale Miquelito wrote:
> >
> >>Please apply this patch for the test suit and see the problem I got 
> >>using revision 915.
> >
> >
> >   I have a stupid problem with py.test - I was running it it with
> >"python -O" that disabled all assertions! I am so sorry for my stupidity.
> >   Now, when I've fixed the problem I see that you don't need to patch
> >test_deep_inheritance.py - test_inherited_ForeignKey.py manifests the bug.
> >
> >   I spend a few hours comparing revision 850 (that works) and the trunk
> >and finally found the difference (though didn't get the reason). I just
> >commited a fix that brings inherited ForeignKeys back. Please test if the
> >revision 944 fixes the problem and does not break anything else.
> 
> Maybe py.test can test for this case (python -O), since certainly it's 
> no good to run py.test with assertions disabled.  Well, I guess you 
> could possibly want to run the tests without assertions; should py.test 
> emit a warning?  Maybe just a little something when py.test is started up:
> 
> try:
>     assert 0
> except AssertionError:
>     pass
> else:
>     print >> sys.stderr, 'Warning: Assertions are turned off! (python -O?)'
> 
> Just while I'm looking at the code, would it be good in 
> py.tests.cmdline.main(), when exiting with KeyboardInterrupt and verbose 
> off, to do print "KeyboardInterrupt (-v to show traceback)" ? 
> Suggestive error messages and all.  I don't know if that assertion test 
> would go in main() or elsewhere.

i added your two suggestions main().  Ian, for changes like this
you can usually just go ahead and commit them.  I can still
correct them if neccessary. 

    holger