[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)

[Timothy Hochberg]

On Mon, Apr 7, 2008 at 10:30 AM, Gael Varoquaux <
gael.varoquaux at normalesup.org> wrote:

> On Mon, Apr 07, 2008 at 10:16:22AM -0700, Timothy Hochberg wrote:
> >    I prefer 'all' for this since it has the correct meaning. 'api'
> assuming
> >    that one can remember what it means doesn't fit. The 'all' module
> would
> >    not contain the api, at least not the preferred api (in my book at
> least),
> >    but it would contain everything.
>
> Sure, but everybody does it different. Convention are important,
> especially in coding. See http://ivory.idyll.org/blog/sep-07/not-sucking
> for a good argumentation about the point. I agree 100% with the author.
> Especially the conclusion.


This is all moot since we agree below, but I don't see that the page your
reference, which seem uncontroversial on a casual reading, is all that
relevant. It's not that I disagree, that following convention is important
where reasonable, I just don't see that this is a case where there is a
convention to follow.

 I'm at a bit of a disadvantage since the convention in question hasn't
penetrated the parts of of Python land that I inhabit (which could either
imply something about my experience or about the universality of the 'api'
convention, take your pick). However, I think that I vaguely recall it from
back in my C-programming days, and as I recall/infer/guess the 'api'
namespace is how you are supposed to use the functions in question, while
the actual modules are split out for implementation purposes only.

However, in numpy, that is not the case. Any splitting of the namespace
would be to support a better, more organized interface, not as an
implementation details. So. referring to the collected, flat namespace as
'api' would be confusing at best since it would imply that was the official
approved way to access the python functions rather than one of two
equivalent apis, where the flat namespace is provided primarily for
beginners.

>
>
> >    If "from numpy.all import *" is really too complicated, which
> although
> >    possible, seems a little disheartening,
>
> How much have you tried forcing Python on people who don't care at all
> about computers.


Almost none, thankfully.


> In my work we spend maybe 2% of our time dealing with
> computers, and the rest struggling with electronics, optics, lasers,
> mechanical design... People don't want to have to learn _anything_ about
> computers. I am not saying they are right, I am however saying that we
> need to provide easy entry point, from where they can evolve and learn.
>


>
> >    I suspect it would be easy enough to have a separate module that
> >    pulled everything in so that you could use "from big_numpy import
> >    *". Or, to preserve backward compatibility, make numpy the unsplit
> >    namespace and expose the split namespace under a different name,
> >    let's say 'np' because that's what I already use as a numpy
> >    abbreviation.
>
> That's the only solution I see wich would make everybody happy. IMHO the
> pylab option is quite nice: matplotlib is nice and modular, but pylab has
> it all. Use whichever you want.
>
> Now the difficulty is to find a good name for the latter
> module/namespace.
>
> Cheers,
>
> Gaël
>
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>
>


-- 
. __
. |-\
.
. tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080407/012aa02c/attachment.html>