You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Otherwise makes things a bit confusing to use.
port buffers are void* and need to be casted to their proper type, but strings could in theory just be always converted to/from python types
Opinions welcome
The text was updated successfully, but these errors were encountered:
I'm not sure what you mean. If a C function has been declared with restype = c_char_p for ctypes, it will already return a bytes string, not a c_char_p instance.
I suppose we could return a str instead, but then we would have to add an encoding parameter to Python functions calling a C function, which returns c_char_p. For example:
The default value could be either the module global ENCODING (value "utf-8"), as shown here, or None, in which case the functions would still return bytes by default and str only if you pass an encoding name.
Since the encoding keyword parameter would be the last parameter and have a default value, you could still call the function in the same way as before. But changing the default return type to str would of course break backwards compatibility.
I meant converting to strings instead of bytes yes.
Is there any valid usecase for returning something other than utf8?
Every single string in jack (and most linux tools) can be assumed to be utf8 unless stated otherwise.
For common calls that return something from jack without user input (like get the version string) the encoding should be set to utf8 without a chance to pick any other, doesnt make sense to me to allow other encodings.
Otherwise makes things a bit confusing to use.
port buffers are void* and need to be casted to their proper type, but strings could in theory just be always converted to/from python types
Opinions welcome
The text was updated successfully, but these errors were encountered: