[Numpy-discussion] future directions

[David Goldsmith]

--- On Thu, 8/27/09, Fons Adriaensen <fons at kokkinizita.net> wrote:

> 2. Adopting that format will make it even more important
> to
> clearly define in which cases data gets copied and when
> not.
> This should be based on some simple rules that can be
> evaluated
> by a code author without requiring a lookup in the
> reference
> 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
> the
> world of numerical Python. It is *very* confusing to a new
> user.

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
> only.
> For example a package that (by its name) suggests it
> provides
> plotting facilities should provide only plotting
> facilities,
> 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?

DG

> Just my two Eurocents of course. 
> 
> Ciao,
>  
> -- 
> FA
> 
> Io lo dico sempre: l'Italia è troppo stretta e lunga.
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>