[moving this to scipy-dev] "Brian Hawthorne" <brian.lee.hawthorne@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