[SciPy-dev] mlabwrap high-level user interface

[Alexander Schmolck]

[moving this to scipy-dev]

"Brian Hawthorne" <brian.lee.hawthorne at gmail.com> writes:

> Ah, forgot one critical use case, the function call!
>
>>>> res = engine.svd(X, nout=1)
>>>> res = engine["svd"](X, nout=1)

As I mentioned in the other poist, I don't like that. There ought to be one
way to do things, and the first type of call is clearly what we'd like
function calls to typically look like.

I suspect that ``engine["svd"]`` ought to be equivalent to ``engine.svd()``.
The reason why I'd at least strongly consider this funny looking behavior that
is that nullary-function call vs. variable lookup is below the interface level
in matlab (i.e. syntactically undistinguishable and hence something that one
is often at liberty to change for a variable that isn't intended for mutation;
a bit like property access can be transparently replaced by a function call in
python (using e.g __getattr__) but not in lesser languages like java or C++).

> This would fall under the exact same code as the raw get below (here
> returning a function proxy). Oh, and one more suggestion, if we're going to
> treat the engine as a dict (which it is), it might also be nice to have a
> keys method to return all the names in the matlab namespace:
>
>>>> mlab_vars = engine.keys()  # or "vars" or "names", whatever

I'm against conflating matlab and MLabWrap-instance method namespaces,
especially since I don't see a very compelling use-case for a ``.keys``
method.

> Though i guess if matlab already has a command for that, you could just use
> that ;) 

Indeed and if there isn't you might have a hard time implementing it anyway ;)

> One nice thing about this design is that the engine object has no
> statically defined public methods, so you don't have to worry so much about
> a method name conflicting with a matlab name.

Yes, I think we really want to avoid that.

> I think it's fine to define a private RawEngine class under the hood which
> implements open, close, get, set, and eval. Then the main user-facing engine
> will just have a reference to it and delegate to it.

Hmm, sorry I'm not 100% sure what you're proposing here -- would RawEngine
essentially be like mlabraw, but ctypes based with a class interface? If so,
yes that would indeed be the approach I'd advocate for the ctypes mlabraw
replacement (the only reason that the C++ code doesn't work like this is that
in the case of mlabraw.cpp the effort involved would IMO not have justified
the reward). IIRC, David's ctypes code already looks like this.

alex