[SciPy-dev] getting test method name

[Alexander Schmolck]

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

> Yes, excellent point. Since it's astronomically unlikely that matlab will
> ever be distributed as a binary RPM from any open repository, it wouldn't
> help much to distribute mlabwrap in that format, as it will probably need to
> be built from source against whatever matlab is installed on the user's
> system. I have not read all the egg documentation yet, is there such a thing
> as a source egg, which will build itself when you install it? Or this is the
> function of easy_install...?

Yup -- I think so, easy_install should allow an out-of-the-box-from-source
install -- at least in cases that don't succumb to the general horrors of
matlab mex/engine extension building that you've experience firsthand.

>
> Footnotes:
>> [1]  I thought me might use something like the following to locally change
>> the
>>      (default) behavior of an MLabWrap instance::
>>
>>          # either a)
>>          with mlab(proxy='never', squeeze=True) as mlab:
>>              x=mlab.some_fun(some_arg)
>>              y=mlab.some_other_fun(*some_more_args)
>>              ...
>>
>>          # or b) just
>>          with mlab(proxy='never', squeeze=True):
>>              ...
>>

> Ha, we are running out of magic syntax hooks! Technically, there's no
> problem using __call__ for this purpose, since the argument to be evaluated
> (as described in the previous design suggestions) will not interfere with
> the keyword arguments. However, there may be some cognitive dissonance on
> the users' part since __call__ would end up being used for two very distinct
> purposes.

Uhm, there could be some cognitive dissonance on my part as well...

> But I can't think of anything better right now.

I can: 

  mlab._do('whatever')

it's just an extra 4 chars typing-overhead and best of all already
implemented. I really don't see the attraction of creating something really
messy just to save 4 keystrokes for bypassing the high-level interface --
something which IMO should neither be often required nor particularly
encouraged. Can you give some examples why you think it's important to make
this more convenient?

> Regarding styles a) and b) above, I personally prefer a), since b) has the
> feeling of a temporary change in state to the primary engine object (even it
> it's not implemented that way)

actually it is (by necessity), at least if I understand you correctly.

> whereas a) is more like clone-with-modifications, which I prefer in general
> because it doesn't require the object you're cloning to be mutable (and I
> always try to reduce mutable state whenever I can).

Yeah, I'm with you on avoiding spurious uses of state.

> Also, it will work without the "with" statement since you could say:
>
>  >>> engine2 = engine(proxy='never', squeeze=True)

Yup -- that's the idea (but this remains true for the other option as well, as
I tried to indicate -- the implementation obviously gets nastier though).
Anyway, I'm happy to go with a) for starters, if we find it doesn't work well
enough we can always implement the more complex scheme.

> As far as reconciling the two different functions of __call__, we can say
> whenever a string is provided for evaluation, do not return a cloned engine,
> but evaluate the string (with the settings provided as keyword args, if
> any). Then whenever a string is *not* provided, always return a cloned
> engine, modified according to the keyword args given.

This looks like it is taken from a perl manpage (i.e. no thanks :)

cheers,

alex