On 25.03.2014 00:06, M.-A. Lemburg wrote: >> [Skip] >> So, to draw this exceedingly long mail to a close, I propose: >> >> 1. PEP 249 should document how stored procedure return values are made >> available to the caller of Cursor.callproc. > > Agreed, we need to address this in some way. > > Since the .callproc() signature is already defined to not return > a procedure/function return value, my proposal was to introduce a > new method .callfunc() which does support this. > > There are a few ways this could be done. The most intuitive is > probably this one: > > Variant A: > ---------- > > return_value = cursor.callfunc(funcname, parameters) > > Unlike the .callproc() method, this call would not support > in/out or output parameters. It would still support creating > result sets, though. > > A less intuitive alternative would be this one: > > Variant B: > ---------- > > return_value_and_result_parameters = cursor.callfunc(funcname, parameters) > > with return_value_and_result_parameters being a sequence of the form > [return_value, parameter0, parameter1, ...], i.e. the return_value > is prepended to the parameters list. > > This would also support in/out and output parameters. > > More Pythonic: > > Variant C: > ---------- > > (return_value, result_parameters) = cursor.callfunc(funcname, parameters) > > This would also support in/out and output parameters and allow to > easily separate the return_value from the result_parameters.
So which of those would you prefer ? Or perhaps someone has an alternative proposal which looks better ? >> 2. PEP 249 should more precisely document how output and in/out >> parameters are specified and processed. > > Agreed as well :-) > > At the moment, the DB-API leaves these details to the database > modules to figure out. -- Marc-Andre Lemburg Director Python Software Foundation http://www.python.org/psf/ _______________________________________________ DB-SIG maillist - DB-SIG@python.org https://mail.python.org/mailman/listinfo/db-sig
