[SciPy-dev] getting test method name

[Brian Hawthorne]

> > For example, omitting the 2.5 dependency, mlabwrap could be distributed
> as
> > an RPM for Fedora 6 (like scipy, numpy, and python).
>
> I'm not sure how good the prospects of that are regardless of python2.5
> dependencies since many of the various versions of matlab in general use
> are
> mutually incompatible at a binary level. Of course this is hardly a
> rebuttal
> of your point, since people with fedora 6 (and fedora 7 will only come out
> this month) and plenty of python packages installed from rpms are unlikely
> to
> be keen on installing 2.5 from source in order to then get a mlabwrap egg.


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...?

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):
>              ...
>
>      With both styles we can also use ``mlab(proxy='never',
> squeeze=True)`` to
>      create a new MlabWrap instance with changed defaults, for the case
> one
>      just wants to customize behavior for a single call, e.g.
>      ``mlab(proxy='never', squeeze=True).some_fun(some_arg)``[2]. In the
> first
>      case (a), we just use the with-statement as a fluid-let and
>      implementation is super-trivial (__enter__ returns self, __exit__
> does
>      nothing). The disadvantage is that this type of shadowing might feel
>      unnatural to pythonistas whilst choosing another name (``... as
> mlab2``)
>      might also feel clumsy; and more importantly if the ``as `` clause is
>      accidentally omitted no error will be raised. Scheme (b) requires
> keeping
>      track of the previous bindings of the __call__ arguments in the newly
>      created instance, setting them in the parent instance and restoring
> the
>      parent's settings on __exit__, which has the disadvantage of being a
> bit
>      contorted.
>
>      BTW, can you think of another way to change defaults? I think we
> might
>      need the __call__ syntax for that (meaning we can't use it for
>      ``mlab._do``), but maybe there's some better possibility I'm
> overlooking.


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.  But  I can't think
of
anything better right now.

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), 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).  Also, it will
work without
the "with" statement since you could say:

  >>> engine2 = engine(proxy='never', squeeze=True)

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.

[2]  Although one could always use the syntax ``mlab.some_fun(some_arg,
>      proxy='never', squeeze=True)`` for the one-off case, I think it the
>      ``mlab(proxy='never', squeeze=True).some_fun(...)`` spelling might be
>      preferable since one might argue that conceptually -- unlike ``nout``
> --
>      these things don't really belong to the function call itself, and who
>      knows, maybe matlab will grow keyword arguments one day.
>

Yes, probably a bad idea to add those settings to the function calls.

-brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/scipy-dev/attachments/20070502/43c46062/attachment-0001.html