[SciPy-dev] mlab namespace thought

Alexander Schmolck a.schmolck@gmx....
Mon Apr 30 04:57:36 CDT 2007

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

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.



More information about the Scipy-dev mailing list