Ethan Quach wrote: > > > Tim Knitter wrote: >> >>> beadm.py - 193,649 - why does the '%' symbol have to be >>> passed in as a variable into the error message string? >> >> It wasn't possible to escape it in the message string so I had to pass >> it in. Python kept interpreting it to be a format character. > > The message isn't correct anyway. A BE name cannot contain many other > characters that you don't have listed there. A BE name may consist of > alphanumeric characters, plus any of [-_.:] > > Without better error information from the library, I think this message > would be better left generic for now --getting rid of the second > sentence altogether, or summarizing the above. >
OK. I got rid of the second sentence. >> >>> libbe.c - 799 - should this somehow be a boolean >>> function instead? >> >> There isn't a way to pass back a true boolean. Or put another way, >> there isn't a boolean format specifier when using Py_BuildValue(). >> There is the "b" specifier but when used it doesn't produce a Python >> "True" or "False". It returns an int so I left this as is. > > Returning an int is fine. I just want us consider what we're > returning here since this interface is being consumed by others, > and we don't have an api defined. So right now you've got the > function returning 0 == Success, 6007 == Failure Why not just > return 0 and 1 ? Yeah I thought about that too and came to the conclusion that as long as the success case was zero the readability of using a a defined enum outweighed using 0 or 1. However 0 and 1 is clearer for consumers so I changed it to that. > > libbe.c - 795 - Its returning a string instead of an int here. > Isn't that going to be a pain for consumers of this function? > Why not just return the failure int code here instead? > fixed. WR updated. Thanks Tim > > > thanks, > -ethan
