Re: [Pyobjc-dev] caution with BOOL parameters

[<bo...@pa...>]

this begs the question: in pyobjc, is the 'c' in a method signature
ONLY used for BOOL types? if so, then maybe the right answer is to
put the test in obj_support.m, ie, change

	case _C_CHR: case _C_SHT:
		return pythonify_c_value(intType, datum);

to something like:

	case _C_SHT:
		return pythonify_c_value(intType, datum);
	case _C_CHR:
		return (pythonify_c_value(intType, datum) != 0);

in general, the programmer should return an expression that evaluates to
0 or 1 for objc bool parameters. but most languages without a true
boolean type permit integer types to be used as boolean
expression without a boolean operator operators. python falls into
this category, and using the bridge should not require a special
idiom for booleans ("always return/pass a boolean expression, not
an int").

i agree that returning only the low 8 bits would be wrong.

--bob

Python 2.2.2 (#1, 02/20/03, 15:23:05)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> print 0==0
1
 >>> print 0==1
0
 >>> print 999999==0
0
 >>> print 999999==123123
0
 >>> print 999999!=123123
1
 >>> if (0): print "true"
... else: print "false"
...
false
 >>> if (5000000000): print "true"   # greater than 2^32-1
... else: print "false"
...
true



On Saturday, March 1, 2003, at 11:27 AM, Ronald Oussoren wrote:
> Boy am I glad I didn't apply a change I was thinking of ;-). I thought 
> BOOL is an unsigned char and was thinking about changing the result of 
> pythonifying a 'char' to a string of lenght 1 (what basicly is the 
> corresponding "type" in Python).
>
> I don't think masking of all but the bottom 8 bits would be a right 
> idea. What if you want to return False from a method of a list of 
> items is empty and True otherwise. The obvious mostly-pythonic way 
> would be:
> 	def myMethod(self):
> 		return len(someList)
>
> This would fail if the length of the list is a multiple of 256.
>
> The right solution for this user-education, too bad we don't have a 
> FAQ yet.
>
> Ronald
>