[SciPy-dev] should scikits.mlawrap require python2.5 [Was: Re: getting test method name]

[Alexander Schmolck]

Sorry, I forgot to fix the subject line, please reply to this email instead,
I'll paste in the same body -- 'as

[sorry, again moving something from email to the list]

"Brian Hawthorne" <brian.lee.hawthorne at gmail.com> writes:
[concerning a backwards-compatibility in mlabwrap's testing.py]
> I noticed though that you added a python >= 2.5 dependency in the
> setup.pyfile in order to have absolute imports.

Yes -- but I reckon we might want to stay a bit more conservative with the
testing stuff since our hope is to get that included somewhere else and since
scipy/matplotlib/numpy still support 2.3, IIRC. If it turns out not to be
needed (or there is little external interest in testing.py anyway), I'd drop
it immediately.

> I finally got matlab installed on my laptop but couldn't build until after
> removing that dependency (because I have py2.4). Since 2.4 is still the
> default version distributed for example with Fedora 6, do you think we could
> just wait a bit before adding a 2.5 dependency?

Sure, if installing python2.5 is inconvenient for you, feel free to revert the
changes (just comment the relevant blocks out). I'll try to at least make some
more headway with the proxying thing before I plan to make use of python 2.5
features (customization of proxying behavior would also be a good candidate
for 2.5-style with-statements, however).

I'm a bit surprised by the implication that fedora (unlike debian or ubuntu)
doesn't manage to support multiple version of python, which sounds pretty
sucky. BTW Is the following any help?

<http://www.serpentine.com/blog/2006/12/22/how-to-build-safe-clean-python-25-rpms-for-fedora-core-6/>


> It helps for everything to be as vanilla as possible. 

Possibly the users, but not necessarily the developers:) Obviously for what's
currently in mlabwrap there is no need to require python 2.5 -- I was just
following Jarrod's idea that, provided we eventually want a 2.5 dependency, we
requiting 2.5 as early as possible would be a good thing (no 2.3/2.4 people
already using it and starting to complain). I think there is a high likelihood
that we'll eventually want to use 2.5 features, esp. with statements[1], but
ctypes out-of-the-box seems also useful ("you need python2.5" is less likely
to lead to confusions than "either 2.5 or python 2.4 with ctypes >= 1.0.1";
BTW what version is the fedora 6 rpm-ctypes?) and there are some other small
conveniences (conditional expressions, partial etc.).

The other thing is that mlabwrap-1.0, which supports pretty much any version
of python, matlab and numpy/numeric, is always available (and could
conceivably even be updated to reflect mlabwrap2.0's API more closely if
necessary).

Anyway, let's defer decision on this for the moment, but I'd be interested to
hear what others think, especially potentialy users. Since Jarrod was OK with
the 2.5 dependency I assume it's not much of a problem for NiPY?

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

cheers,

'as


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.


[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.
_______________________________________________
Scipy-dev mailing list
Scipy-dev at scipy.org
http://projects.scipy.org/mailman/listinfo/scipy-dev