[Numpy-discussion] future directions
Thu Aug 27 19:56:00 CDT 2009
--- On Thu, 8/27/09, Fons Adriaensen <email@example.com> wrote:
> 2. Adopting that format will make it even more important
> clearly define in which cases data gets copied and when
> This should be based on some simple rules that can be
> by a code author without requiring a lookup in the
> docs each time.
I think this is a _good_ idea (I don't know how easy/difficult it would be to implement, though; perhaps the most difficult part would be the human side, i.e., settling on a policy to implement.)
> 3. Finally remove all the redundancy and legacy stuff from
> world of numerical Python. It is *very* confusing to a new
I like this also (but I also know that actually trying to achieve it would ruffle a lot of feathers).
> 4. Ensure that each package deals with one problem area
> For example a package that (by its name) suggests it
> plotting facilities should provide only plotting
> and not spectra, averages of all sorts, etc.
I thought #3 was "Finally." ;-) Seriously though, can you be more specific as to where you see this problem presently in NumPy? For example, NumPy doesn't presently have a plotting package... (MatPlotLib is not a NumPy package - it is an independent package that uses NumPy, but it is not part of NumPy - picking nits, perhaps, but it's a nit I'm sure many would beg to pick.)
> 5. Ensure some consistency in style. Some numerical Python
> packages use two-character function names, some a have
> veryLongCamelCased names.
Again, where exactly do you see this problem presently in NumPy?
> Just my two Eurocents of course.
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
> NumPy-Discussion mailing list
More information about the NumPy-Discussion