[SciPy-dev] pynotes

[Arnd Baecker]

On Mon, 8 Nov 2004, Prabhu Ramachandran wrote:

>  "AB" == Arnd Baecker <arnd.baecker at web.de> writes:

[...]

>     AB> Maybe I am missing something here, but from my point of view
>     AB> the only remaining problem is to get a unique path to
>     AB> `ufuncs`.  I don't see how storing in a dictionary will
>     AB> overcome this - sorry if I am just blind.
>
> Well, what if the version changes, or the path to the file changes

Very valid point!
> (like you install the default rpm/deb and then upgraded to a source
> install in /usr/local) or if the version of Python changes.  But then
> again if you made the paths using only module names rather than the
> __file__ then this would work fine I guess.

We only have to make sure that for example commenting on
plot for scipy.xplt does not get mangled up with plot
from scipy.plt etc.

[...]

>     AB> To elaborate a bit more on the `ufunc` problem:
> [...]
>
> Yes, that is a problem. /the only solution I know is to use a separate
> ufunc directory and treat all names as common to anything that is a
> ufunc.

Yes, that would be the solution (I fear ;-).
BTW: how does one properly find out if an object is a 'ufunc'
I looked in types, Numeric.types (which is the same) in Numeric
and did not find something like a UfuncType.
As workaround I would do
  obj=Numeric.sin ; type(obj)==type(Numeric.cos)
I there anything better?

> Is there any reason numarray's cos function will be documented
> any different from Numeric's?

Well, at least for exp from Numeric one might want to add a comment
that there is safe_exp from Fernando helping with overflow/underflow.
(A problem which does not exist on the numarray side, as I far
as I understood).
But for the numarrray side we don't get problems
as there one can get the full path, even for ufuncs.

> BTW, instead of using the full path why not strip everything before
> the site-packages (for the __file__) because it eliminates the problem
> with versioning and relocating the package to /usr/local etc.

I originally had it that way. At some point I thought
(but I can't recall the argument now) that it would
be better to store the full path.
But indeed your remark about a new python version
is very valid. So if the <module>.__file__ contains
  /usr/lib/python2.3/
(like for math,
  /usr/lib/python2.3/lib-dynload/math.so
)
one could strip that part.
(So one has to find out where the python modules
are installed. One could just get the path for `os` for
example,
In [6]: import os
In [7]: os.__file__
Out[7]: '/usr/lib/python2.3/os.pyc'
assume that this is unaltered and
   os.path.split(os.__file__)[0]
gives on the part to strip off.
Fine so far.

Now what about relocated packages, to /usr/local etc.,
How do I know what to strip off to get the same string
which was used for the not relocated one?
I fear that might depend where one really installs it?
And then one might have privately installed additional
modules sitting anywhere on the hard-disk.
I am not sure if there is a good general way to treat
those as well.
(Of course, if we keep the full path and they are
not moved around we will get the added notes).

So maybe one strategy would be to strip off what
one finds from os.path.split(os.__file__)[0]
(so we would be save through python upgrades -
very important point, I agree).
and leave the full path if this string is not found.

Drawback: no good solution for relocated modules.
Consequences: requires further thinking ;-)

Arnd














> cheers,
> prabhu
>
> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev at scipy.net
> http://www.scipy.net/mailman/listinfo/scipy-dev
>