Menu
▾
▴
numpy-discussion
|
From: Todd M. <jm...@st...> - 2003-05-13 21:49:19
|
As has been mentioned before, we're planning to repackage numarray as a package rather than as a collection of modules. We're soliciting comments now because we only want to do this once. Here are the planned renamings for the numarray modules as we transition to a package: numarray --> numarray.numeric recarray --> numarray.records chararray --> numarray.strings ndarray --> numarray.generic * --> numarray.* Note that class and function names will remain unchanged, so recarray.RecArray will become numarray.records.RecArray. Here are the planned renamings for the current and planned add-on packages consolidated into a single add-ons distribution: LinearAlgrebra2 --> numarray.LinearAlgebra FFT2 --> numarray.FFT RandomArray2 --> numarray.RandomArray Convolve --> numarray.Convolve Convolve.Image --> numarray.Image MA2 --> numarray.MA Future 3rd party packages should locate themselves under the numarray.addons sub-package: * --> numarray.addons.* The package name (shown here as numarray) is still undecided. By including stub modules which emulate the "import behavior" of numarray-0.5, we'll make it possible to ignore / work around the effects of the re-packaging for the time being. The stub modules will be activated either through the creation of a .pth file or via additions to PYTHONPATH to make them visible. Comments? |
|
From: David M. C. <co...@ph...> - 2003-05-13 22:15:37
|
On Tue, May 13, 2003 at 05:50:07PM -0400, Todd Miller wrote: > As has been mentioned before, we're planning to repackage numarray as > a package rather than as a collection of modules. We're soliciting > comments now because we only want to do this once. ... > Future 3rd party packages should locate themselves under the > numarray.addons sub-package: > > * --> numarray.addons.* What's the rationale for having a separate place for third-party packages? Shouldn't they just install themselves as their own packages or modules? (i.e., in site-packages/) -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |co...@ph... |
|
From: Gerard V. <gve...@gr...> - 2003-05-14 07:24:33
|
On Tue, 13 May 2003 18:13:31 -0400 "David M. Cooke" <co...@ph...> wrote: > On Tue, May 13, 2003 at 05:50:07PM -0400, Todd Miller wrote: > > As has been mentioned before, we're planning to repackage numarray as > > a package rather than as a collection of modules. We're soliciting > > comments now because we only want to do this once. > ... > > Future 3rd party packages should locate themselves under the > > numarray.addons sub-package: > > > > * --> numarray.addons.* > > What's the rationale for having a separate place for third-party > packages? Shouldn't they just install themselves as their own packages > or modules? (i.e., in site-packages/) > I like the idea, because it would mean that I can release my PyQwt plot package so that it can be build for Numeric and numarray on the same system. It reduces the risk of calling 'PyQwt for numarray' functions with 'Numeric arrays' as arguments and vice-versa (for me it seems to work, but it scares me to death). Gerard |
|
From: Konrad H. <hi...@cn...> - 2003-05-14 09:26:16
|
> I like the idea, because it would mean that I can release my PyQwt > plot package so that it can be build for Numeric and numarray > on the same system. It reduces the risk of calling 'PyQwt for numarray' I'd like to check that this doesn't cause any technical problems with pac= kage=20 managers, distutils, etc. Otherwise it will prevent people from switching= to=20 numarray. Konrad. --=20 -------------------------------------------------------------------------= ------ Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------= ------ |
|
From: Francesc A. <fa...@op...> - 2003-05-14 09:45:16
|
A Dimecres 14 Maig 2003 09:24, Gerard Vermeulen va escriure: > > I like the idea, because it would mean that I can release my PyQwt > plot package so that it can be build for Numeric and numarray > on the same system. It reduces the risk of calling 'PyQwt for numarray' > functions with 'Numeric arrays' as arguments and vice-versa (for me it > seems to work, but it scares me to death). I think this is not necessary as you can always distinguish if the user i= s passing a numarray or Numeric object, like in: In [3]: a=3DNumeric.array([1,2]) In [4]: b=3Dnumarray.array([1,2]) In [5]: type(a) Out[5]: <type 'array'> In [6]: type(b) Out[6]: <class 'numarray.NumArray'> It's just a check before accessing the object. Cheers, --=20 Francesc Alted |
|
From: Kasper S. <Kas...@ir...> - 2003-05-14 10:02:29
|
> > Future 3rd party packages should locate themselves under the > > numarray.addons sub-package: > > > > * --> numarray.addons.* > > What's the rationale for having a separate place for third-party > packages? Shouldn't they just install themselves as their own packages > or modules? (i.e., in site-packages/) Maybe it's nice to have both. Leave it to the third-party to decide whether it's a good idea to install in numarray.addons or in site-packages/. For stuff that's not too dependent on numpy (PyGame for instance) it would be better to install in site-packages/. For other things (like PyQwt) it might be better to locate them in numarray.addons. bye, Kasper |
|
From: Konrad H. <hi...@cn...> - 2003-05-14 09:28:05
|
On Tuesday 13 May 2003 23:50, Todd Miller wrote: > Here are the planned renamings for the numarray modules as we transitio= n > to a package: > > numarray --> numarray.numeric > recarray --> numarray.records > chararray --> numarray.strings > ndarray --> numarray.generic > * --> numarray.* > > Note that class and function names will remain unchanged, so > recarray.RecArray will become numarray.records.RecArray. > > Here are the planned renamings for the current and planned add-on packa= ges > consolidated into a single add-ons distribution: > > LinearAlgrebra2 --> numarray.LinearAlgebra > FFT2 --> numarray.FFT > RandomArray2 --> numarray.RandomArray > Convolve --> numarray.Convolve > Convolve.Image --> numarray.Image > MA2 --> numarray.MA Please use a uniform capitalization scheme, no matter which one. Either=20 numarray.image or Numarray.Image (I prefer the latter, but both are bette= r=20 than the mixed one). Konrad. --=20 -------------------------------------------------------------------------= ------ Konrad Hinsen | E-Mail: hi...@cn... Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.56.24 Rue Charles Sadron | Fax: +33-2.38.63.15.17 45071 Orleans Cedex 2 | Deutsch/Esperanto/English/ France | Nederlands/Francais -------------------------------------------------------------------------= ------ |
|
From: Todd M. <jm...@st...> - 2003-05-14 11:07:40
|
David M. Cooke wrote: >On Tue, May 13, 2003 at 05:50:07PM -0400, Todd Miller wrote: > > >>As has been mentioned before, we're planning to repackage numarray as >>a package rather than as a collection of modules. We're soliciting >>comments now because we only want to do this once. >> >> >... > > >>Future 3rd party packages should locate themselves under the >>numarray.addons sub-package: >> >>* --> numarray.addons.* >> >> > >What's the rationale for having a separate place for third-party >packages? Shouldn't they just install themselves as their own packages >or modules? (i.e., in site-packages/) > > > I think there are two goals which are served by numarray.addons: 1. It becomes clear what is in the numarray core, and what isn't. This is a maintenance issue. 2. It becomes clear that a particular extension was built explicitly for numarray. This might be valuable in a transition phase from Numeric to numarray. Todd |
|
From: Todd M. <jm...@st...> - 2003-05-14 11:30:06
|
Konrad Hinsen wrote: >On Tuesday 13 May 2003 23:50, Todd Miller wrote: > > > >>Here are the planned renamings for the numarray modules as we transition >>to a package: >> >>numarray --> numarray.numeric >>recarray --> numarray.records >>chararray --> numarray.strings >>ndarray --> numarray.generic >>* --> numarray.* >> >>Note that class and function names will remain unchanged, so >>recarray.RecArray will become numarray.records.RecArray. >> >>Here are the planned renamings for the current and planned add-on packages >>consolidated into a single add-ons distribution: >> >>LinearAlgrebra2 --> numarray.LinearAlgebra >>FFT2 --> numarray.FFT >>RandomArray2 --> numarray.RandomArray >>Convolve --> numarray.Convolve >>Convolve.Image --> numarray.Image >>MA2 --> numarray.MA >> >> > >Please use a uniform capitalization scheme, no matter which one. Either >numarray.image or Numarray.Image (I prefer the latter, but both are better >than the mixed one). > >Konrad. > > Point taken. I guess that changes the addon mappings to: LinearAlgrebra2 --> numarray.linear_algebra FFT2 --> numarray.fft RandomArray2 --> numarray.random_array Convolve --> numarray.convolve Convolve.Image --> numarray.image MA2 --> numarray.ma or changes everything to: numarray --> Numarray.Numeric recarray --> Numarray.Records chararray --> Numarray.Strings ndarray --> Numarray.Generic * --> Numarray.* LinearAlgrebra2 --> Numarray.LinearAlgebra FFT2 --> Numarray.FFT RandomArray2 --> Numarray.RandomArray Convolve --> Numarray.Convolve Convolve.Image --> Numarray.Image MA2 --> Numarray.MA I have no preference myself (obviously!). Lower case and underscores may be more in line with our group's style. Todd |
|
From: Andrew P. L. Jr. <bs...@al...> - 2003-05-14 20:09:58
|
On Wed, 14 May 2003, Todd Miller wrote: > Point taken. I guess that changes the addon mappings to: > > LinearAlgrebra2 --> numarray.linear_algebra > FFT2 --> numarray.fft > RandomArray2 --> numarray.random_array > Convolve --> numarray.convolve > Convolve.Image --> numarray.image > MA2 --> numarray.ma I prefer this naming scheme as it helps visually delineate between modules and classes. ie: numarray.linear_algebra.LUMatrix is likely to be a class numarray.linear_algebra.lumatrix is likely to be a module It seems that most people use StudlyCaps for class names in Python. While there aren't a lot of times that this matters, I have bumped into this more often than I expect. But I may just be doing odd things with modules. -a |
|
From: Todd M. <jm...@st...> - 2003-05-14 11:54:39
|
Francesc Alted wrote: >A Dimecres 14 Maig 2003 09:24, Gerard Vermeulen va escriure: > > >>I like the idea, because it would mean that I can release my PyQwt >>plot package so that it can be build for Numeric and numarray >>on the same system. It reduces the risk of calling 'PyQwt for numarray' >>functions with 'Numeric arrays' as arguments and vice-versa (for me it >>seems to work, but it scares me to death). >> >> > >I think this is not necessary as you can always distinguish if the user is >passing a numarray or Numeric object, like in: > >In [3]: a=Numeric.array([1,2]) > >In [4]: b=numarray.array([1,2]) > >In [5]: type(a) >Out[5]: <type 'array'> > >In [6]: type(b) >Out[6]: <class 'numarray.NumArray'> > > >It's just a check before accessing the object. > >Cheers, > > > I think installing in numarray.addons (or not) is a package-by-package decision. Some packages might prefer to be independent. That's fine. Others might prefer (or require) dedicated versions, particularly those packages which use compiled extensions. For those instances where dedicated versions are necessary, numarray.addons is a recommendation to keep clear seperation between core numarray (maintained and distributed by one group) and software which has been layered on it (maintained and distributed by other groups). Todd |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X