On 10 Apr 2008, at 05:21, Travis E. Oliphant wrote:
Right now it looks like there is a mix of attitudes, about the
financial
functions. They are a small enough addition, that I don't think it
matters terribly much what we do with them. So, it seems to me that
keeping them in numpy.lib
Sorry to be late on this thread, but I was out of town, and I do feel
strongly about this issue.
Gael Varoquaux wrote:
For the beginner, from numpy.all import * is more confusing than from
numpy import * (which is already confusing).
except that the beginner, nor anyone else, should ever use
On Wed, Apr 09, 2008 at 11:27:04AM -0700, Christopher Barker wrote:
Gael Varoquaux wrote:
For the beginner, from numpy.all import * is more confusing than from
numpy import * (which is already confusing).
except that the beginner, nor anyone else, should ever use import *
anyway!
Right!
2008/4/9, Gael Varoquaux [EMAIL PROTECTED]:
[snip]
Some people do not want their scripts to scale or to last more than a day.
And that's what Matlab is especially good at ! ; )
And I'll say the thing I'm dying to say since this started: If anybody other
than Travis had suggested we put
On Wed, Apr 09, 2008 at 04:18:41PM -0400, David Huard wrote:
And that's what Matlab is especially good at ! ; )
Exactly. I would like to have the same ease of use for beginners than
Matlab. The reason being that _I_ would be able develop my own module using the
powerful feature of Python, but
Gael Varoquaux wrote:
the beginner, nor anyone else, should ever use import *
Right! Sure. Tell this to a medical doctor who just wants to learn as
little things as possible about a computer in order to process his MRI
data and finish his PhD to never have to worry anymore with stupid
On Wed, Apr 9, 2008 at 3:57 PM, Jarrod Millman [EMAIL PROTECTED] wrote:
Absolutely. Let's please standardize on:
import numpy as np
import scipy as sp
See:
http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines
http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py
On Wed, Apr 9, 2008 at 4:57 PM, Jarrod Millman [EMAIL PROTECTED] wrote:
On Wed, Apr 9, 2008 at 11:27 AM, Christopher Barker
[EMAIL PROTECTED] wrote:
except that the beginner, nor anyone else, should ever use import *
anyway!
+1
Namespaces are one honking great idea -- let's do more
On Mittwoch 09 April 2008, Charles R Harris wrote:
import numpy.linalg as la ?
Yes! :)
Andreas
signature.asc
Description: This is a digitally signed message part.
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
And I'll say the thing I'm dying to say since this started: If anybody
other than Travis had suggested we put financial functions in numpy
the response would have been: make it a scikit, let the functions
mature and evolve, get some feedback from users and then we'll see
where they fit
Hi Chris
On 09/04/2008, Christopher Barker [EMAIL PROTECTED] wrote:
I have yet to advocate that the Matlab users in my group (The Scientists
that happen to need a bit of programming, but have no interest in it)
start using Python, but, frankly, import *, and minor syntax like that
has
Perry Greenfield wrote:
...
Some random comments:
1) It seems to me that the primary problem people have with a big
flat namespace is that it makes the output of dir() long and
unusable, and by implication, that a nice hierarchical organization
would make it easier for people to find
On Tue, Apr 08, 2008 at 06:15:25AM -0600, Steven H. Rogers wrote:
At the IPython Sprint in Boulder last year Fernando suggested that
someone look at this issue. I've given it some thought and started a
wiki page for it. Inputs would be welcome and might motivate me to find
the time to
On Tue, April 8, 2008 07:28, Gael Varoquaux wrote:
...
http://ipython.scipy.org/doc/ipython1/html/
http://ipython.scipy.org/doc/ipython1/ipython1.pdf
Sphinx seems a very promising to the everlasting problem of documentation.
Thanks for bringing this up. I need to look at Sphinx.
Regards,
On Tue, Apr 8, 2008 at 2:23 PM, Steven H. Rogers [EMAIL PROTECTED] wrote:
On Tue, April 8, 2008 07:28, Gael Varoquaux wrote:
...
http://ipython.scipy.org/doc/ipython1/html/
http://ipython.scipy.org/doc/ipython1/ipython1.pdf
Sphinx seems a very promising to the everlasting
Fernando Perez wrote:
On Tue, Apr 8, 2008 at 2:23 PM, Steven H. Rogers [EMAIL PROTECTED] wrote:
On Tue, April 8, 2008 07:28, Gael Varoquaux wrote:
...
http://ipython.scipy.org/doc/ipython1/html/
http://ipython.scipy.org/doc/ipython1/ipython1.pdf
Sphinx seems a very
2008/4/4, Joe Harrington [EMAIL PROTECTED]:
import numpy as N
import numpy.math as N.M
import numpy.trig as N.T
import numpy.stat as N.S
I don't think the issue is whether to put everything in the base namespace
// everything in individual namespace, but rather to find an optimal and
On 07/04/2008, David Huard [EMAIL PROTECTED] wrote:
2008/4/4, Joe Harrington [EMAIL PROTECTED]:
import numpy as N
import numpy.math as N.M
import numpy.trig as N.T
import numpy.stat as N.S
I don't think the issue is whether to put everything in the base namespace
// everything
On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote:
I agree, and I think we can come to some compromise -- maybe a
numpy.all namespace, that simply imports all the other subpackages.
For the beginner, from numpy.all import * is more confusing than from
numpy import * (which is
On 07/04/2008, Gael Varoquaux [EMAIL PROTECTED] wrote:
On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote:
I agree, and I think we can come to some compromise -- maybe a
numpy.all namespace, that simply imports all the other subpackages.
For the beginner, from numpy.all
On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote:
You're only a beginner for a short while, and after that the lack of
namespaces really start to bite. I am all in favour of catering for
those who are busy learning numpy, but should we do that at the cost
of our advanced
On Mon, Apr 7, 2008 at 9:57 AM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote:
You're only a beginner for a short while, and after that the lack of
namespaces really start to bite. I am all in favour of catering for
those who
On Mon, April 7, 2008 11:16, Timothy Hochberg wrote:
If from numpy.all import * is really too complicated, which although
possible, seems a little disheartening, 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
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),
On Mon, Apr 7, 2008 at 10:30 AM, Gael Varoquaux
[EMAIL PROTECTED] 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
Steven H. Rogers wrote:
On Mon, April 7, 2008 11:16, Timothy Hochberg wrote:
If from numpy.all import * is really too complicated, which although
possible, seems a little disheartening, I suspect it would be easy enough
to
have a separate module that pulled everything in so that you could
On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey [EMAIL PROTECTED] wrote:
Hi,
I think that splitting the NumPy namespace should not happen within a
major release series because it would cause too many breakages. Rather
it should be in a forthcoming release like the 2.0 series where it may
On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote:
I would prefer not to do it at all. We've just gotten people moved
over from Numeric; I'd hate to break their trust again.
+1.
Gaël
___
Numpy-discussion mailing list
On Mon, Apr 7, 2008 at 11:29 AM, Gael Varoquaux
[EMAIL PROTECTED] wrote:
On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote:
I would prefer not to do it at all. We've just gotten people moved
over from Numeric; I'd hate to break their trust again.
+1
I also think we have a big
On Montag 07 April 2008, Robert Kern wrote:
I would prefer not to do it at all. We've just gotten people moved
over from Numeric; I'd hate to break their trust again.
+1.
IMO, numpy has arrived at a state where there's just enough namespace clutter
to allow most use cases to get by without
On Mon, Apr 7, 2008 at 11:02 AM, Timothy Hochberg [EMAIL PROTECTED] wrote:
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'
On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote:
On Montag 07 April 2008, Robert Kern wrote:
I would prefer not to do it at all. We've just gotten people moved
over from Numeric; I'd hate to break their trust again.
+1.
IMO, numpy has arrived at a state where there's just
On Mon, Apr 07, 2008 at 10:16:57PM +0200, Stéfan van der Walt wrote:
Would it therefore make sense to
a) Reorganise numpy to expose functionality as numpy.api.*
b) Do a series of imports in numpy.__init__ which pulls in from numpy.api.
This way, numpy.* would look exactly as it does now, bar
I wouldn't exactly call 494 functions just enough namespace clutter;
I'd much prefer to have a clean api to work with
I don't know. The 494 functions do not seem like many to me.
Apparently, I tend to come down in the flat earth society although I
do like some structure (after all that's
On Montag 07 April 2008, Stéfan van der Walt wrote:
I wouldn't exactly call 494 functions just enough namespace clutter;
I'd much prefer to have a clean api to work with.
Not to bicker, but...
import numpy
len(dir(numpy))
494
numpy.__version__
'1.0.4'
funcs = [s for s in dir(numpy) if
On 07/04/2008, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Would it therefore make sense to
a) Reorganise numpy to expose functionality as numpy.api.*
b) Do a series of imports in numpy.__init__ which pulls in from numpy.api.
This way, numpy.* would look exactly as it does now,
On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote:
On Montag 07 April 2008, Stéfan van der Walt wrote:
I wouldn't exactly call 494 functions just enough namespace clutter;
I'd much prefer to have a clean api to work with.
Not to bicker, but...
import numpy
len(dir(numpy))
On Mon, Apr 07, 2008 at 11:21:41PM +0200, Stéfan van der Walt wrote:
It doesn't matter *what* these completions are -- they're still there.
Sifting through 500 options isn't fun
I get more than that when I tab in an empty shell on my box.
:-}
Why do you expect to be able to inspect a module
On Mon, Apr 7, 2008 at 3:21 PM, Stéfan van der Walt [EMAIL PROTECTED]
wrote:
On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote:
On Montag 07 April 2008, Stéfan van der Walt wrote:
I wouldn't exactly call 494 functions just enough namespace
clutter;
I'd much prefer to have a
On Apr 7, 2008, at 2:29 PM, Robert Kern wrote:
On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey [EMAIL PROTECTED]
wrote:
Hi,
I think that splitting the NumPy namespace should not happen
within a
major release series because it would cause too many breakages.
Rather
it should be
3) Some don't like the bloat (in disk space or download sizes) of
adding things to numpy. In my case, as long as the addition doesn't
make installations any more difficult I don't care. For the great
majority, the current size or anything within an order of magnitude
is not an important
On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
The only problem is that if we keep adding things to numpy that could
be in scipy, it will _never_ be clear to users where they can expect
to find things. It is already bad enough. How do I explain to a
user/student/scientist that ffts and
On Mon, Apr 7, 2008 at 4:03 PM, Perry Greenfield [EMAIL PROTECTED] wrote:
On Apr 7, 2008, at 5:54 PM, Brian Granger wrote:
The only problem is that if we keep adding things to numpy that could
be in scipy, it will _never_ be clear to users where they can expect
to find things. It
+1 (and s/students/colleagues).
Surely you mean:
s.replace('students', colleagues')
!
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Every once in a while the issue of how to split things into packages
comes up. In '04, I think, we had such a discussion regarding scipy
(with Numeric as its base at the time). One idea was a
core-plus-many-modules approach. We could then have metapackages that
just consisted of dependencies
On Fri, 04 Apr 2008, Joe Harrington wrote:
Wouldn't you rather do:
import numpy as N
...
c = (N.sin(b) + N.exp(d)) / N.mean(g)
rather than:
import numpy as N
import numpy.math as N.M
import numpy.trig as N.T
import numpy.stat as N.S
...
c = (N.T.sin(b) + N.M.exp(d)) /
On Fri, Apr 04, 2008 at 04:29:03PM -0400, Alan Isaac wrote:
import numpy as N
import numpy.math as N.M
import numpy.trig as N.T
import numpy.stat as N.S
...
c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g)
I try to think of my students in such an environment.
Frightening.
+1
47 matches
Mail list logo
