[SciPy-dev] Fwd: mlabwrap high-level user interface

[Alexander Schmolck]

> Agreed, a single way to do things is preferable to multiple arbitrary
> choices. I was thinking of rarer cases for the dictionary style lookup, with
> attribute style being the common use case. For example:
>
>  1)  Building layers on top (like an object browser), one might like to
> say:
>
>       >>> for name in engine.names: do_something_with(engine[name])
>
>       But I guess in such a case, you could always just use the built-in
> getattr function.

Yup.

>  2) Name conflicts. In the rare case that some lunatic named a matlab
>     variable "__getattr__",
>      you could retrieve its value with engine["__getattr__"], whereas
> engine.__getattr__ would
>      return a bound python method.

Ah, that's not a problem -- a big part of the reason that things like
``mlab._get`` and ``mlab._do`` start with an underscore is that legal matlab
names don't. So currently name conflicts really *can't* happen and this is a
reason I'd like to keep "non-private" methods out.

Actually, there is one additional wrinkle: to allow for identifiers that are
legal in matlab but not in python (prime example: ``print``), a final trailing
'_' is stripped on the way to matlab (e.g. ``mlab.print_`` -> ``print`` in
matlab); but this name-mangling is obviously bijective, so there are still no
name clashes, but to achieve consistency lookup methods such as ``._get`` or
the one you proposed (mlab['print']) should maybe also implement it (i.e.
mangle 'print_' and even throw an error on 'print', because it is a python
keyword). This is currently not the case.


>> 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++).
>
>
> Hmm, that does throw a wrench in the works

Well, not necessarily. Although I'd suspect that quite a few users of matlab
are not aware of the fact that ``x = inf`` does involve a function call
(``inf()``), I'm not sure that on the whole it would cause much problems
interface-breakage to resolve ``mlab.x`` to a variable getting operation, if
``x`` is a variable and not a function -- in fact I suppose this is quite
negligible (since it would only constants that where reimplemented as
functions (or vice versa), not something that I think occurs often). Can
anyone think of examples?

Another consideration is that this would prevent users from just assigning
things to a matlab instance or the MlabWrap class, which is something that I
think can be useful (e.g. to customize the default ``nout`` (etc.) value for a
certain function ``f`` you can now just do:

  mlab.f = mlab._make_mlab_command('f, nout=3, doc=mlab._raw_eval("help('f)"))

).

Lastly performance related considerations: given the terrible performance of
all matlab engine calls means that this scheme could be close to 2x slower
(two engine calls engEvalString + engGetVariable) than mlab['x'] (one engine
call: engGetVariable) in some cases; it would also render the memoizing that
currently happens on ``getattr(mlab, x)`` more problematic.

So, in summary, I think that treating ``mlab.x`` as variable lookup/assignment
when ``x`` is a matlab variable is in principle feasible -- the downsides and
difficulties I see are not overwhelming, but I currently would favor using
``mlab['x']`` for variables and reserving ``mlab.x`` for functions, unless
someone can come up with a compelling argument. Unlike the __call__ syntax, I
don't see anything else that the ``[]`` syntax could be used for instead,
either.

cheers,

'as