[SciPy-dev] More bugs fixed
rkern at ucsd.edu
Fri Oct 7 11:33:17 CDT 2005
Stephen Walton wrote:
> Robert Kern wrote:
>>I *would* prefer that the modules under scipy_core be separate from the
>>modules in scipy proper.
> I am a bit muddled by this thread. Right now, scipy.stats is not in
> scipy_core, but in scipy proper (and newscipy). Robert had said earlier
> he wanted scipy.stats removed from scipy_core; does he mean that
> scipy.stats was formerly intended to move from scipy to scipy_core, and
> he no longer wants this to happen? At this point I want to put in a
> good word for scipy.stats.ppcc_plot, ppcc_max, and their cousins.
There was a scipy.stats in scipy_core up until last night. Before I
checked in mtrand, it contained a fair bit of Python code to expand the
interface provided by the ranlib extension module. It did not have all
of the distributions and statistics functions that were in the old
scipy.stats. Travis's original plan was for the subpackages in scipy
proper (which would be much-expanded from what is in scipy_core) to
simply overwrite the ones in scipy_core when they get installed. For a
number of reasons, I don't think this is going to work.
Now that I've checked in mtrand, there really weren't anymore interface
issues, so scipy/stats/__init__.py in scipy_core became really tiny.
Since having scipy.stats in both scipy_core and scipy proper (by which I
mean "what's currently in the newscipy branch") is problematic, we've
removed scipy.stats from scipy_core, and all of the random number
generators are available from scipy.random .
scipy.stats.ppcc_plot and all of the rest will be available with the
complete scipy, worry not.
> What is the consensus about which packages from scipy move to the core?
> I take it that
Probably no more packages. Perhaps a few functions may find their way
over. That linalg, fftpack, and random are in scipy_core at all probably
has more to do with the desire to provide just as much capability as
Numeric than anything else.
> Perhaps the main cause of my muddle-ment is whether we're talking about
> scipy_core and scipy SVN trunks or the newscipy and newcore branches at
> any given moment. I see a bunch of new stuff in the newscipy sandbox now.
Yes, I can see where that would be confusing. What's in the trunks are
currently dead ends. They will be replaced by the branches reasonably
soon. FWIW, when I talk about scipy_core and scipy proper, I mean what
are currently in the newcore and newscipy branches, respectively. If I'm
talking about the dead ends, I'll usually say "old scipy" or something
scipy is dead! Long live scipy!
>>At the moment, I have scipy_core and scipy
>>built as separate eggs with proper namespace package support.
> Eggs sounds like a really nice technology. How do we feel about making
> it the default way to distribute prebuilt scipy binaries?
I would love for that to be the case. They probably *will* be the way
I'm distributing binaries for OS X. There are still issues with
EasyInstall and non-root installs on UNIX-type systems with anal
sysadmins/distros. The problem has been getting quite a bit of attention
recently, so I'm no longer the only one badgering Phillip Eby about it.
rkern at ucsd.edu
"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
More information about the Scipy-dev