Re: [SQLObject] sqlobject test suite weirdness

[Ian B. <ia...@co...>]

Victor Ng wrote:
>>OK, I don't entirely understand that.  It is a normal ISO-8859-1
>>character, though.  Exactly which test is this?  Well,
>>u'\u00f0'.encode('iso-8859-1') == '\xf0'.
> 
> 
> I've reverted the code and commited it back to SVN.  The test case is
> sqlobject/tests/test_unicode.py
> 
> How do i run just 1 test function?  I want to do something like:
> 
> $ py.test sqlobject/tests/test_unicode.py/test_create

I think

$ py.test -k create sqlobject/tests/test_unicode.py


>>>I'm also getting some odd behavior with the test_blob module where
>>>bytes aren't coming back as expected.
>>
>>Is FormEncode up to date?  There was a bug in the ordering of
>>conversions that caused problems with that.
> 
> 
> I just updated and installed from FormEncode's trunk and I still get
> this in the test_create test case:
> 
> E       assert prof2.image == data
> 
>>      assert <ImageData 1 image="'">.image == '\x00\x01\x02\x03\x04\x05\x06\x07\x08\t\n\x0b\x0c\r\x0e\x0f\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f !"#$%&\'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\x7f\x80\x81\x82\x83\x84\x85\x86\x87\x88\x89\x8a\x8b\x8c\x8d\x8e\x8f\x90\x91\x92\x93\x94\x95\x96\x97\x98\x99\x9a\x9b\x9c\x9d\x9e\x9f\xa0\xa1\xa2\xa3\xa4\xa5\xa6\xa7\xa8\xa9\xaa\xab\xac\xad\xae\xaf\xb0\xb1\xb2\xb3\xb4\xb5\xb6\xb7\xb8\xb9\xba\xbb\xbc\xbd\xbe\xbf\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd7\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1\xe2\xe3\xe4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5\xf6\xf7\xf8\xf9\xfa\xfb\xfc\xfd\xfe\xff'

I don't have any particular ideas at the moment.  Further investigation 
is required ;)  It doesn't seem to be showing what prof2.image really is 
either.  If it is some kind of Binary() object, then it's a case where 
the validator/converter isn't coercing it back to a string.

>>>py.test also seems to barf up on error which I can't seem to figure
>>>out, but I'm not really used to py.test quite yet.  My brain is still
>>>in unittest/doctest mode. :)
>>
>>There's a couple times py.test's magic doesn't work right.  You can turn
>>it off with an error.  One thing that can be difficult is Collector
>>errors, which are essentially errors on import, which happen in
>>SQLObject fairly often (since all the classes are created on import).
> 
> 
> How do I turn off the error?

py.test --nomagic --nocapture --fulltrace

>>There's also a question about how much safety wwe care about.  For
>>instance, _SO_writeLock seems to keep us from doing duplicate queries in
>>some conditions.  But only very few conditions; is the very occassional
>>spurious query a problem?  Probably not.  But in another case it might
>>be possible to expire an object, and then while the expiration is
>>happening you could refetch the data, and potentially get the object in
>>a weird state where it is half-expired and all messed up.
> 
> 
> Ok - I'm willing to buy that answer for now.  I'm going to try and get
> my profiler integrated into my branch so that I can actually measure
> the cost of all this locking.  If the cost is high, then can we at
> least consider dropping the locks?

If the cost is high we can try to figure out just what is required. 
Correctness coming first, of course ;)


-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org