Re: Suggestion on priorities for improving pytave

[Mike Miller]

On Thu, Jul 07, 2016 at 02:31:18 +0530, Abhinav Tripathi wrote:
> I have tried many more things but still am stuck at the point where Tatsuro
> was stuck on the building pytave on windows front (or probably I couldn't
> even reach that point).

Please make some notes, at some point it might be nice to get a summary
of what has been done so far and what the blockers are, either in a
README or on the wiki.

> So, I have thought to start on some other improvements to pytave.
> I wanted to know your thoughts on priority/acceptance of any of the
> following changes:
> .
> 1- remove ALL the numpy stuff from octave_to_python.cc in order to store
> everything directly into corresponding python types. Might take some time
> to complete but should be straight forward.

Agree with Colin, I think we may want to keep numpy for arrays. Needs
some thought put into it. It may be possible to remove it if it's easy
enough to construct a numpy array from an Octave array. But that mode of
operation, whether done implicitly or explicitly, should remain easy.

Once the pyobject stuff is merged, though, you could look at removing
some of the other non-array conversions, for example the automatic
conversions to cell arrays and struct arrays.

> 2 - add a new 'pystore.{h,  cc}' to allow users to store a variable into
> python directly. In many cases we have to either make a proxy function and
> use pycall to store values in a list by calling that proxy function. This
> new function would really help.

Sorry, I'm not sure I follow. Can you demonstrate with some code what
you mean by this? I'm all for making it easier to convert Octave data
types into Python, just not sure what use case you are talking about.

> 3 -  extend pycall.cc to support arbitrary number of parameters by storing
> all the prameters in a python array (pystore could come in handy here), say
> '_tmp_args_array' and then use something like
> pyeval("function_to_call(*_tmp_args_array)")
> The same capability can be used in @pyobject class to call functions with
> arbitrary number of arguments.

Yes, not sure about the method you describe, but definitely adding
support for arbitary argument lists, and also unpacking multiple return
values.

Maybe some kind of support for function kwargs as well? A scalar struct
to pass named parameters?

> 4 -  Start getting rid of all the boost stuff from all the files. This
> might take much time and can probably prove a little dificult at places.
> But since Mike said he wanted pytave to be not dependent on boost, it can
> be a place to start.

Yes, and this could easily be done incrementally. As you've seen and
started doing in your PRs, you can mix and match the Python native API
with the Boost.Python API to some extent.

I have been idle on pytave for the past week or so, but I am hoping to
get back into it and review and merge all of the work you and Colin have
been putting into it. Once I get all of the outstanding PRs and issues
handled, I will try to brainstorm some more immediate ideas for
improvements.

Thank you for your contributions so far!

-- 
mike