[SciPy-user] How to solve name mangling ?

David Cournapeau david at ar.media.kyoto-u.ac.jp
Fri Jun 8 05:47:28 EDT 2007


Stef Mientki wrote:
>
> Steve and Stefan (and my name is Stef and was Stephan  ;-),
>
>  From a pure programmers point of view you might be fully right.
> btw I don't want to start a flame war,
> but from a non-programmers point of view (which is a growing group, me 
> falling somewhere in between),
> reading the philosophy behind Python, I come to a totally different 
> conclusion
>
>  From what I remember some philosophical highlights are:
>   Python should be intuitively, simple, universal and allow many 
> solutions for the same problem.
Python philosophy generally highlights one good solution for a given 
problem...
>
> To drive my car,
> - I don't need to know the type of the spark-plug
> - I don't need to know how many spark-plugs my car has
> - I don't need to know if my car has any spark-plugs
> - I might even have never heard of a spark-plug
>
> To use Python,
> - I need to know what an numpy array is
> - I need to know what a numeric array is
> - I need to know what an array array is
> - I need to know what a scipy array is
> - and maybe a few others ...
>
I've never used numeric or "array array", and there is no such a thing 
as scipy array... I find the analogy with a car totally bogus because in 
most countries anyway, you need to get a permit to drive, and this takes 
more time than typing many times N.foo instead of foo (at least it did 
for me). And anyway, driving a car without paying attention to what you 
are doing is the cause of many deaths every year :)

Namespaces is one of the top reason why I started using python instead 
of matlab (a bit behind the not broken C api reason). There are so many 
weird things happening in matlab because of the lack of namespace (which 
only becomes worse because foo(1) can be the first element of foo or the 
function foo called with 1, and the fact that there is the stupid limit 
one public function / one m file).

This may sound minor to you, N.sum vs sum, but this has *major* 
consequences for the whole codebase. Also, being explicit is easier than 
being implicit, not the contrary. For example, what do you thing is the 
easiest ? Typing numpy.sum(a, 1) or tracking down a bug because sum(a, 
1) gives you a totally bogus result (python sum and numpy sum are 
different) ? And it happens (one recent bug in scipy was exactly caused 
by that).

> But I just want to use an array,
> and I just want that the array always to behave the same,
> even if I give the array to someone else.
>
> Ok, a car has a much longer history than programming languages.
> And "batteries included" is both the strong point and the weak point of 
> a language like Python.
>
>  From the viewpoint of the non-programmer,
> who just wants to drive their car (without wanting to have a look inside 
> the car),
> there is still no good answer :-(
yes there is: call N.sum instead of sum in your module. Look at it that 
way: how many N. do you need to write, and how many character have you 
written instead in this email ?

David



More information about the SciPy-User mailing list