On Tue, Sep 29, 2009 at 4:10 PM, Bernie Innocenti bernie@codewiz.org wrote:
El Tue, 29-09-2009 a las 12:36 +0000, Aleksey Lim escribió:
I suspect the #1 usecase for numpy is to compensate for lack of good array support in Python.
Questions:
- are there lighter-weight alternatives for the most popular uses of
numpy?
How about numarray?
$ rpm -q --requires python-numarray /bin/sh /usr/bin/env libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit) libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit) libpthread.so.0()(64bit) libpython2.6.so.1.0()(64bit) python(abi) = 2.6 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(VersionedDependencies) <= 3.0.3-1 rtld(GNU_HASH) rpmlib(PayloadIsXz) <= 5.2-1
- how many of the existing activities actually depend on numpy?
Peter answered this
- would it be hard to remove this dependency from them?
I seem to recall several Python apps moving from numpy to numarray in the past, so it should be doable. If we want to do this, we should probably create a tracker bug in Bugzilla.
- Should we define a policy for deprecating components of the Sugar
Platform in new revisions? All evolving standards need to find a balance between new features with old feature removal to avoid unbounded bloat.
That sounds reasonable. Like "new activities using numpy will not be accepted"? If the porting work from numpy to numarray is documented, this should be linked to from the policy as well, so that people can adapt their activities.
- Even if numpy is going to stay around for the Sugar Platform, could
we remove it from Pippy and other core activities to save resources and allow shipping lighter weight live distros?
Probably a good thing to do, yes.
Regards,