Hi Matthew, [I think this is likely to be of interest to other mlabwrap developers as well, so I hope it's OK if I move this to scipy-dev, and re-arrange to bottom-posting style. Sorry it took me some time to get back on this -- I've taken longer than expected to readjust to my European day-cycle]

...

"Matthew Brett" <matthew.brett@gmail.com> writes:

...

Hi,

I was just thinking about the problem of the kludginess of

...

...

...

from mlabwrap import mlab import mlabraw A, B, C = mlab.svd([[1,2],[1,3]], 0, nout=3) pymat.put(mlab._session, "X", [[1,2], [1,3]])

It seems to me the problem is the fact that the mlab namespace has to be kept free of anything that could be a matlab function.

So how about:

import mlab from mlab import exec as mle

A, B, C = mle.svd([[1,2],[1,3]], 0, nout=3) mlab.put(X, [[1,2], [1,3]]) On 4/23/07, Alexander Schmolck <a.schmolck@gmx.net> wrote:

Hi Matthew,

why not just use

mlab._set('X', [[1,2], [1,3]])

:)

alex

...

Best,

"Matthew Brett" <matthew.brett@gmail.com> writes:

Yer - sorry - I forgot that your're right. :)

But, in general, you've got the problem that any new method of attribute in the mlab module has to be preprended with an underscore, which is a bit awkward - as you know, the underscore is in general a semi-formal clue to the programmer that the feature is private and should not be used outside the module itself. I speak only for myself, but I have the instinct to think hard before I use an underscore function or attribute. And it makes it difficult for you to indicate which functions etc are really private and which are not.

Agreed -- there's still double-underscore, but that has name-mangling implications; OTOH

I realize this would mean an API change in mlabwrap...

I can definitely see where you're coming from -- It is true that underscore method names carry a strong connotation with "messing with internals", but there are two considerations why I prefer the current scheme to having several objects: 1. There's a good technical reason why there's a single ``mlab`` that mediates access to a matlab session, rather than several handles for different purposes (``mle`` etc.): mlabwrap supports multiple matlab sessions and each such session is encapsulated in a MlabWrap class instance -- ``mlab`` is just the 'default' session that gets created as one imports mlabwrap. If one uses different objects to interface to a single session, synchronization issues can arise (e.g. one's ``mle`` might in fact accidentally refer to a different session than one's ``mlab``). 2. Finally, getting and setting variables, *is*, to my mind "messing with internals" -- the interface metaphor of mlabwrap is that matlab is a python library -- you call functions in the mlab "module" just like in any other module and the things you pass in and get out are python objects (possibly proxying matlab objects). Setting named variables in matlab-space is lower-level than that The main use case I see for it is querying and setting global variables that control the behavior of a matlab package (or matlab itself). Whilst I'd be happy to give greater prominence to ``mlab._set`` and ``mlab._get`` in the documentation (and I think de-emphasizing mlabraw might also be a good idea) or reserve the dictionary access notation for this use as Brian suggested, my feeling is that it is not that often needed. If you have some other, non-marginal use case it would really be good if you could send me some examples. I think that it'd be feasible to think up a more "natural" way to handle such variable setting (e.g. one could possibly make ``mlab.some_global_var = 3`` work; but there are some difficulties associated with doing that; e.g. the syntactic equivalence between nullary function call and variable access in matlab; see my other post or scipy.org/MlabWrap) if there is a demonstrated need. More on this in my replies to Brian. cheers, alex