[vlc-devel] Announce: brand new python bindings (ctypes-based)

[Olivier Aubert]

On Fri, 2009-07-31 at 10:28 +0200, Sébastien Escudier wrote:
> Quoting Olivier Aubert <olivier.aubert at liris.cnrs.fr>:
> 
> > Looks OK to me, except for one case: what about functions returning
> > values? Your scheme works for void functions (that can then return an
> > error code), for functions returning pointers (that can return NULL in
> > case of error), but is not appliable to functions returning values.
> > What is your plan here?
> 
> we could have special values (like negative values) for errors. We can also add
> a pointer parameter to the function.
Special values are no good solution, because 1/ it breaks prototyping
and 2/ introduces special cases for different return types.
1/ illustration: the audio_get_volume function returns an unsigned int.
If you want to use a negative  number as error code, you have to turn
this into 'int', which evidently does not convery the appropriate
information.
2/ illustration: imagine two functions that return an int (say
audio_get_volume, which returns positive integers, and
equalizer_get_threshold for instance, which could probably return
negative integers), how am I supposed to know that negative values are
an error code in the first case, and an appropriate return value in the
other one ? And moreover, how do I convey an error code for the second
one?

As for the pointer parameter to the function, I guess that goes against
the KISS  principle that Remi wants to achieve in the redesign.

A possible suggestion: since it is intended anyway to have a per-thread
error message variable, why not make it a per-thread struct (error code+
error message), which would be always set in case of error (and .code
would remain 0 if ok). Functions for checking error code status would be
implemented (in fact, it would not even change a lot from current
status: libvlc_exception_raised, libvlc_exception_get_message would
simply be parameterless).

This behaviour is compatible with the use of return values (at the cost
of writing some more code when returning errors, but appropriate macros
clearly alleviate that), allows specifying errors for functions
returning values (the programmer can check the error status in all cases
for such functions. Moreover, it can also be used to provide error codes
for functions returning NULL pointers in case of error), and provides a
reasonably generic mechanism that can easily be automatically translated
into exceptions.

In fact, this proposal sums up in removing the libvlc_exception_t*
parameter from functions, and putting it in a per-thread variable. Looks
reasonable to me.

Olivier