From millman at berkeley.edu  Sat May  1 16:26:39 2010
From: millman at berkeley.edu (Jarrod Millman)
Date: Sat, 1 May 2010 13:26:39 -0700
Subject: [SciPy-Dev] preparing for scipy 0.8 release
In-Reply-To: <l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
References: <u2jdde7764a1004250405x26e33f46i365e8f4679c382b5@mail.gmail.com> 
	<hr2gkq$ois$1@dough.gmane.org>
	<q2ndde7764a1004260441qbeb3c920h96a2a20e384e553c@mail.gmail.com>
	<l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
Message-ID: <q2sc7009a551005011326k528fc020zeb7c7f987f4ea14b@mail.gmail.com>

On Tue, Apr 27, 2010 at 6:30 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> Here's a proposal for the release schedule:
> 30/05: create 0.8.x branch, beta available, trunk open to add py3k
> compatibility
> 11/06: 0.8 release candidate 1
> 22/06: 0.8 release
>
> 15/08: create 0.9.x branch, first beta
> 22/08: 0.9 release candidate 1
> 01/09: 0.9 release
>
> How does this sound?

Sounds good!
Jarrod


From lasagnadavide at gmail.com  Sun May  2 07:36:19 2010
From: lasagnadavide at gmail.com (Davide Lasagna)
Date: Sun, 2 May 2010 13:36:19 +0200
Subject: [SciPy-Dev] Faster implementation of the Savitsky-Golay filter.
In-Reply-To: <r2pb26d2191005010559t74e3dc4dhdf12549c1930ba11@mail.gmail.com>
References: <r2pb26d2191005010559t74e3dc4dhdf12549c1930ba11@mail.gmail.com>
Message-ID: <h2jb26d2191005020436u35ffddcby40b5c3c9cd81908c@mail.gmail.com>

Hi all,

I have come up with a much faster implementation of the Savitsky-Golay
filter function proposed in the Cookbook at
http://www.scipy.org/Cookbook/SavitzkyGolay.

I have tweaked the code in the cookbook and removed the two loops at the end
of the function with a call to np.convolve. The speed up is in excess of a
hundred.

I have attached the code. Can someone update the relevant scipy wiki page?

Moreover, is there a chance that such function will be part of scipy?

Regards,

Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100502/cb337cf5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: savitsky_golay.py
Type: text/x-python
Size: 1619 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100502/cb337cf5/attachment.py>

From ralf.gommers at googlemail.com  Tue May  4 09:51:31 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 4 May 2010 21:51:31 +0800
Subject: [SciPy-Dev] preparing for scipy 0.8 release
In-Reply-To: <q2y5b8d13221004292008z394c98fas926abb265cc65341@mail.gmail.com>
References: <u2jdde7764a1004250405x26e33f46i365e8f4679c382b5@mail.gmail.com>
	<hr2gkq$ois$1@dough.gmane.org>
	<q2ndde7764a1004260441qbeb3c920h96a2a20e384e553c@mail.gmail.com>
	<l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
	<q2y5b8d13221004292008z394c98fas926abb265cc65341@mail.gmail.com>
Message-ID: <r2idde7764a1005040651ud2a3c028v16a9fd7dc02c3413@mail.gmail.com>

On Fri, Apr 30, 2010 at 11:08 AM, David Cournapeau <cournape at gmail.com>wrote:

> On Tue, Apr 27, 2010 at 10:30 PM, Ralf Gommers
>
> > Here's a proposal for the release schedule:
> > 30/05: create 0.8.x branch, beta available, trunk open to add py3k
> > compatibility
> > 11/06: 0.8 release candidate 1
> > 22/06: 0.8 release
> >
> > 15/08: create 0.9.x branch, first beta
> > 22/08: 0.9 release candidate 1
> > 01/09: 0.9 release
> >
> > How does this sound?
>
> Sounds good to me, but it means numpy 2.0 has to be out soon too (its
> release schedule should be earlier than scipy, the earlier the
> better),
>
> Yes I was assuming that numpy 2.0 would be out by September, if not then
the 0.9 release has to wait for that.

It seems this schedule works for everyone that replied, so let's keep it as
is.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100504/f69ee13c/attachment.html>

From ralf.gommers at googlemail.com  Tue May  4 10:02:25 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 4 May 2010 22:02:25 +0800
Subject: [SciPy-Dev] Fortran cleanup advice?
In-Reply-To: <hrcn8p$ec3$2@dough.gmane.org>
References: <p2ndde7764a1004260629u279a764if4073882093b1643@mail.gmail.com>
	<hr4kd8$hb3$1@dough.gmane.org>
	<s2wdde7764a1004281713nd94e0ebn9fdca642dc4f0270@mail.gmail.com>
	<hrcn8p$ec3$2@dough.gmane.org>
Message-ID: <q2gdde7764a1005040702k6016f4d8v4df8fa83e6f39c99@mail.gmail.com>

On Fri, Apr 30, 2010 at 3:39 AM, Pauli Virtanen <pav at iki.fi> wrote:

> Thu, 29 Apr 2010 08:13:14 +0800, Ralf Gommers wrote:
> > On Tue, Apr 27, 2010 at 2:01 AM, Pauli Virtanen
> > <pav+sp at iki.fi <pav%2Bsp at iki.fi><pav%2Bsp at iki.fi <pav%252Bsp at iki.fi>>
> >> wrote:
> [clip]
> >> Scipy-specific code is of course a different matter -- warnings from
> >> code written by Scipy authors should be fixed.
> >
> > That was kind of my problem - those get lost in the noise now.
>
> Ok, that's a valid point.
>
> I'm not sure how to implement passing the correct flags to Fortran
> compilers here. Sounds like it may require some changes to
> numpy.distutils.fcompiler, unless the silencing flags are already listed
> there.
>
> Ok I will try to get this to work, either in fcompiler, or in build_clib as
David suggests.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100504/83f4cd51/attachment.html>

From d.l.goldsmith at gmail.com  Tue May  4 18:54:40 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 4 May 2010 15:54:40 -0700
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing attention
Message-ID: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>

Hi, all.  Joe asked me to prepare this, and I thought it might be of
"universal" interest to those working on the docs.  Following each milestone
is the number of docstrings therein needing editing attention, i.e., in
either the "Needs editing" or the "Being Written" state (based solely on
their background color), as of today, May 4, 2010.

All docstring from http://docs.scipy.org/scipy/docs/. 2584

Milestones/Milestones_1<http://docs.scipy.org/scipy/Milestones/Milestones_1/>Cluster,
Constants 54

Milestones/Milestones_2<http://docs.scipy.org/scipy/Milestones/Milestones_2/>FFT,
Integration 58

Milestones/Milestones_3<http://docs.scipy.org/scipy/Milestones/Milestones_3/>Interpolation
77

Milestones/Milestones_4<http://docs.scipy.org/scipy/Milestones/Milestones_4/>Input
/ Output 254 (most in io.matlab)

Milestones/Milestones_5<http://docs.scipy.org/scipy/Milestones/Milestones_5/>Blas,
Linear Algebra 130

Milestones/Milestones_6<http://docs.scipy.org/scipy/Milestones/Milestones_6/>Max.
Entropy, Misc., Image Manip. 173

Milestones/Milestones_7<http://docs.scipy.org/scipy/Milestones/Milestones_7/>Ortho.
dist. regr., Optimization 100

Milestones/Milestones_8<http://docs.scipy.org/scipy/Milestones/Milestones_8/>Signal
processing 119

Milestones/Milestones_9<http://docs.scipy.org/scipy/Milestones/Milestones_9/>Sparse
Matrices 325

Milestones/Milestones_10<http://docs.scipy.org/scipy/Milestones/Milestones_10/>Spatial
Algorithms., Special funcs. 266

Milestones/Milestones_11<http://docs.scipy.org/scipy/Milestones/Milestones_11/>Statistical
functions 473

Milestones/Milestones_12<http://docs.scipy.org/scipy/Milestones/Milestones_12/>Image
Array Manipulation, Convolution 47

Milestones/Milestones_13<http://docs.scipy.org/scipy/Milestones/Milestones_13/>C/C++
Integration 508

FWIW,

DG

-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100504/4d0f9b29/attachment.html>

From ralf.gommers at googlemail.com  Tue May  4 19:39:23 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 5 May 2010 07:39:23 +0800
Subject: [SciPy-Dev] Update on the "Needs editing" numpy docstrings
In-Reply-To: <y2x45d1ab481004282324lb82e1280v71a2e0bc38c64d62@mail.gmail.com>
References: <y2x45d1ab481004282324lb82e1280v71a2e0bc38c64d62@mail.gmail.com>
Message-ID: <m2ydde7764a1005041639w924803ccr3d0e3d5a207cc7b6@mail.gmail.com>

On Thu, Apr 29, 2010 at 2:24 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> Hi, all!  I've been working on the remaining "Needs editing" status numpy
> docstrings, of which there are presently 74.  I've compiled two lists: those
> I think might be classifiable as "Unimportant," and those I think might
> require somewhat lengthy docstrings (the latter list is meant to try to
> recruit helpers). ;-)  Here are those lists:
>

Hi David, thanks for the update.

Except for polytemplate.rel_import (which someone already moved to
unimportant) I think all of these still need to be written. They are all
useful, so don't move them. For the ones no one with the right expertise has
time for, just leave them as they are - at some point the blanks will be
filled in.

Cheers,
Ralf


>     List of potentially "Unimportant"s
> timeinteger (autogenerated subclass of signedinteger)
> timedelta64 (autogenerated subclass of timeinteger)
> polytemplate.rel_import
> Everything in distutils that still has status "Needs editing"
> linalg (docstring - which consists of tables of objects - auto-generated?)
> lib.shape_base.get_array_wrap
> f2py.diagnose and its "Needs editing" status attributes
> numpy.lib._iotools.StringConverter.iterupgrade
> dtype.base and dtype.metadata
>
>     List of potentially "long" ones
> All "Needs editing" status doc.*
> core.umath, core.shape_base, core.function_base
> numpy-docs/*
>
> If you have opinions on these (or if you look at the whole list of
> remaining "Needs editing" docstrings and feel that I've left some off the
> "Unimportant" list) please do chime in.
>
> Thanks,
>
> DG
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100505/078cab30/attachment.html>

From josef.pktd at gmail.com  Tue May  4 19:58:13 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 4 May 2010 19:58:13 -0400
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
Message-ID: <y2w1cd32cbb1005041658l7d908605ub4515d3749db9785@mail.gmail.com>

On Tue, May 4, 2010 at 6:54 PM, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> Hi, all.? Joe asked me to prepare this, and I thought it might be of
> "universal" interest to those working on the docs.? Following each milestone
> is the number of docstrings therein needing editing attention, i.e., in
> either the "Needs editing" or the "Being Written" state (based solely on
> their background color), as of today, May 4, 2010.
>
> All docstring from http://docs.scipy.org/scipy/docs/. 2584
>
> Milestones/Milestones_1 Cluster, Constants 54
>
> Milestones/Milestones_2 FFT, Integration 58
>
> Milestones/Milestones_3 Interpolation 77
>
> Milestones/Milestones_4 Input / Output 254 (most in io.matlab)
>
> Milestones/Milestones_5 Blas, Linear Algebra 130
>
> Milestones/Milestones_6 Max. Entropy, Misc., Image Manip. 173
>
> Milestones/Milestones_7 Ortho. dist. regr., Optimization 100
>
> Milestones/Milestones_8 Signal processing 119
>
> Milestones/Milestones_9 Sparse Matrices 325
>
> Milestones/Milestones_10 Spatial Algorithms., Special funcs. 266
>
> Milestones/Milestones_11 Statistical functions 473

I copied some depreciation warnings into the docstrings and changed
them to unimportant, e.g

http://docs.scipy.org/scipy/docs/scipy.stats.stats.mean/

What's the format for a warning/admonition directive and for
update/changes/removal notices?

Josef

>
> Milestones/Milestones_12 Image Array Manipulation, Convolution 47
>
> Milestones/Milestones_13 C/C++ Integration 508
>
> FWIW,
>
> DG
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From warren.weckesser at enthought.com  Tue May  4 20:04:39 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Tue, 04 May 2010 19:04:39 -0500
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
Message-ID: <4BE0B617.2070200@enthought.com>

Is there an explanation somewhere of the connection between the 
docstrings in the source and the docstrings visible at docs.scipy.org?  
I've made an assortment of changes (via svn) in scipy.linalg and 
scipy.signal, including the module-level docstrings, but I don't see the 
changes on the web page.  For example,
    http://docs.scipy.org/scipy/docs/scipy-docs/linalg.rst/
is not up to date.

Warren


David Goldsmith wrote:
> Hi, all.  Joe asked me to prepare this, and I thought it might be of 
> "universal" interest to those working on the docs.  Following each 
> milestone is the number of docstrings therein needing editing 
> attention, i.e., in either the "Needs editing" or the "Being Written" 
> state (based solely on their background color), as of today, May 4, 2010.
>
> All docstring from http://docs.scipy.org/scipy/docs/. 2584
>
> Milestones/Milestones_1 
> <http://docs.scipy.org/scipy/Milestones/Milestones_1/> Cluster, 
> Constants 54
>
> Milestones/Milestones_2 
> <http://docs.scipy.org/scipy/Milestones/Milestones_2/> FFT, Integration 58
>
> Milestones/Milestones_3 
> <http://docs.scipy.org/scipy/Milestones/Milestones_3/> Interpolation 77
>
> Milestones/Milestones_4 
> <http://docs.scipy.org/scipy/Milestones/Milestones_4/> Input / Output 
> 254 (most in io.matlab)
>
> Milestones/Milestones_5 
> <http://docs.scipy.org/scipy/Milestones/Milestones_5/> Blas, Linear 
> Algebra 130
>
> Milestones/Milestones_6 
> <http://docs.scipy.org/scipy/Milestones/Milestones_6/> Max. Entropy, 
> Misc., Image Manip. 173
>
> Milestones/Milestones_7 
> <http://docs.scipy.org/scipy/Milestones/Milestones_7/> Ortho. dist. 
> regr., Optimization 100
>
> Milestones/Milestones_8 
> <http://docs.scipy.org/scipy/Milestones/Milestones_8/> Signal 
> processing 119
>
> Milestones/Milestones_9 
> <http://docs.scipy.org/scipy/Milestones/Milestones_9/> Sparse Matrices 325
>
> Milestones/Milestones_10 
> <http://docs.scipy.org/scipy/Milestones/Milestones_10/> Spatial 
> Algorithms., Special funcs. 266
>
> Milestones/Milestones_11 
> <http://docs.scipy.org/scipy/Milestones/Milestones_11/> Statistical 
> functions 473
>
> Milestones/Milestones_12 
> <http://docs.scipy.org/scipy/Milestones/Milestones_12/> Image Array 
> Manipulation, Convolution 47
>
> Milestones/Milestones_13 
> <http://docs.scipy.org/scipy/Milestones/Milestones_13/> C/C++ 
> Integration 508
>
>
> FWIW,
>
> DG
>
> -- 
> Mathematician: noun, someone who disavows certainty when their 
> uncertainty set is non-empty, even if that set has measure zero.
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From ralf.gommers at googlemail.com  Tue May  4 20:13:44 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 5 May 2010 08:13:44 +0800
Subject: [SciPy-Dev] Faster implementation of the Savitsky-Golay filter.
In-Reply-To: <h2jb26d2191005020436u35ffddcby40b5c3c9cd81908c@mail.gmail.com>
References: <r2pb26d2191005010559t74e3dc4dhdf12549c1930ba11@mail.gmail.com>
	<h2jb26d2191005020436u35ffddcby40b5c3c9cd81908c@mail.gmail.com>
Message-ID: <j2ydde7764a1005041713t975abbew588c7d55649a75a0@mail.gmail.com>

On Sun, May 2, 2010 at 7:36 PM, Davide Lasagna <lasagnadavide at gmail.com>wrote:

> Hi all,
>
> I have come up with a much faster implementation of the Savitsky-Golay
> filter function proposed in the Cookbook at
> http://www.scipy.org/Cookbook/SavitzkyGolay.
>
> I have tweaked the code in the cookbook and removed the two loops at the
> end of the function with a call to np.convolve. The speed up is in excess of
> a hundred.
>
> I have attached the code. Can someone update the relevant scipy wiki page?
>

You can update that page yourself, it's a wiki. You just need to register
first.

>
> Moreover, is there a chance that such function will be part of scipy?
>

This would be a very useful addition I think. It would need tests, a more
informative docstring that conforms to the numpy standard and reformatting
to keep the lines shorter than 80 chars. Where it could go I'm not sure,
probably scipy.interpolate or scipy.signal.

In the cookbook page it is stated that "A much better solution would be to
extend the signal with its mirror image." Did you consider the
implementation given?

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100505/ea6a442f/attachment.html>

From d.l.goldsmith at gmail.com  Tue May  4 20:55:05 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 4 May 2010 17:55:05 -0700
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <4BE0B617.2070200@enthought.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
	<4BE0B617.2070200@enthought.com>
Message-ID: <u2i45d1ab481005041755kfe83aec6r881f0d8767834a26@mail.gmail.com>

On Tue, May 4, 2010 at 5:04 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Is there an explanation somewhere of the connection between the
> docstrings in the source and the docstrings visible at docs.scipy.org?
> I've made an assortment of changes (via svn) in scipy.linalg and
> scipy.signal, including the module-level docstrings, but I don't see the
> changes on the web page.  For example,
>    http://docs.scipy.org/scipy/docs/scipy-docs/linalg.rst/
> is not up to date.
>

Just to be sure: you actually opened up the docs in question in the Wiki -
as opposed to merely judging by their background color - correct?  (Via the
Wiki is the only way to update the status of a docstring, whether or not you
edit it there, i.e., if you edit a docstring in source and commit the change
in svn, the Wiki will still show the docstring as being in Needs editing (or
Being written, or whatever).

More generally, and in full recognition of the fact that it's not as
convenient to do it this way, "we" really strongly prefer docstrings to be
edited via the Wiki.  Why?  Well, among other reasons, perhaps the most
important is that the Wiki was intentionally and carefully designed to
"enforce" as many strictures of the Docstring Standard as possible.  (I put
enforce in quotes because it allows you to submit non-conforming changes,
but it complains about them loudly in red, so anyone who looks at the
docstring later in the Wiki, e.g., a reviewer, will be able to tell at a
glance if a docstring is non-conforming).

The "proper" thing to do at this point is to open up for editing in the Wiki
the docstrings you edited elsewhere and cut-and-paste your work there.  Add
a comment documenting what you've done, preview, if there are
mark-up/standard compliance problems, fix them, etc., etc., and finally, if
you regard the result as ready for review, change the status accordingly (or
change it to being written if you save changes but don't yet regard it as
"finished").  Obviously, all I can do is ask you to do this...

DG


>
> Warren
>
>
> David Goldsmith wrote:
> > Hi, all.  Joe asked me to prepare this, and I thought it might be of
> > "universal" interest to those working on the docs.  Following each
> > milestone is the number of docstrings therein needing editing
> > attention, i.e., in either the "Needs editing" or the "Being Written"
> > state (based solely on their background color), as of today, May 4, 2010.
> >
> > All docstring from http://docs.scipy.org/scipy/docs/. 2584
> >
> > Milestones/Milestones_1
> > <http://docs.scipy.org/scipy/Milestones/Milestones_1/> Cluster,
> > Constants 54
> >
> > Milestones/Milestones_2
> > <http://docs.scipy.org/scipy/Milestones/Milestones_2/> FFT, Integration
> 58
> >
> > Milestones/Milestones_3
> > <http://docs.scipy.org/scipy/Milestones/Milestones_3/> Interpolation 77
> >
> > Milestones/Milestones_4
> > <http://docs.scipy.org/scipy/Milestones/Milestones_4/> Input / Output
> > 254 (most in io.matlab)
> >
> > Milestones/Milestones_5
> > <http://docs.scipy.org/scipy/Milestones/Milestones_5/> Blas, Linear
> > Algebra 130
> >
> > Milestones/Milestones_6
> > <http://docs.scipy.org/scipy/Milestones/Milestones_6/> Max. Entropy,
> > Misc., Image Manip. 173
> >
> > Milestones/Milestones_7
> > <http://docs.scipy.org/scipy/Milestones/Milestones_7/> Ortho. dist.
> > regr., Optimization 100
> >
> > Milestones/Milestones_8
> > <http://docs.scipy.org/scipy/Milestones/Milestones_8/> Signal
> > processing 119
> >
> > Milestones/Milestones_9
> > <http://docs.scipy.org/scipy/Milestones/Milestones_9/> Sparse Matrices
> 325
> >
> > Milestones/Milestones_10
> > <http://docs.scipy.org/scipy/Milestones/Milestones_10/> Spatial
> > Algorithms., Special funcs. 266
> >
> > Milestones/Milestones_11
> > <http://docs.scipy.org/scipy/Milestones/Milestones_11/> Statistical
> > functions 473
> >
> > Milestones/Milestones_12
> > <http://docs.scipy.org/scipy/Milestones/Milestones_12/> Image Array
> > Manipulation, Convolution 47
> >
> > Milestones/Milestones_13
> > <http://docs.scipy.org/scipy/Milestones/Milestones_13/> C/C++
> > Integration 508
> >
> >
> > FWIW,
> >
> > DG
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> > uncertainty set is non-empty, even if that set has measure zero.
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100504/e1e748fc/attachment.html>

From josef.pktd at gmail.com  Tue May  4 21:37:09 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 4 May 2010 21:37:09 -0400
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <u2i45d1ab481005041755kfe83aec6r881f0d8767834a26@mail.gmail.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
	<4BE0B617.2070200@enthought.com>
	<u2i45d1ab481005041755kfe83aec6r881f0d8767834a26@mail.gmail.com>
Message-ID: <r2y1cd32cbb1005041837k916bd546wad7eafbdc4bf4db0@mail.gmail.com>

On Tue, May 4, 2010 at 8:55 PM, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> On Tue, May 4, 2010 at 5:04 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>>
>> Is there an explanation somewhere of the connection between the
>> docstrings in the source and the docstrings visible at docs.scipy.org?
>> I've made an assortment of changes (via svn) in scipy.linalg and
>> scipy.signal, including the module-level docstrings, but I don't see the
>> changes on the web page. ?For example,
>> ? ?http://docs.scipy.org/scipy/docs/scipy-docs/linalg.rst/
>> is not up to date.

There might also be merge conflicts, if there were independent changes
both in the doc editor and in the source, that need to be manually
resolved

http://docs.scipy.org/scipy/docs/scipy.signal.ltisys.lsim2/

I don't know why this doesn't indicate a conflict:
http://docs.scipy.org/scipy/docs/scipy-docs/signal.rst/

step2 is in source, but doesn't show in edit, nor in  "Diff to SVN"
changes that were made in the doc editor are there

step2 is not in the doceditor according to a search

Josef

>
> Just to be sure: you actually opened up the docs in question in the Wiki -
> as opposed to merely judging by their background color - correct?? (Via the
> Wiki is the only way to update the status of a docstring, whether or not you
> edit it there, i.e., if you edit a docstring in source and commit the change
> in svn, the Wiki will still show the docstring as being in Needs editing (or
> Being written, or whatever).
>
> More generally, and in full recognition of the fact that it's not as
> convenient to do it this way, "we" really strongly prefer docstrings to be
> edited via the Wiki.? Why?? Well, among other reasons, perhaps the most
> important is that the Wiki was intentionally and carefully designed to
> "enforce" as many strictures of the Docstring Standard as possible.? (I put
> enforce in quotes because it allows you to submit non-conforming changes,
> but it complains about them loudly in red, so anyone who looks at the
> docstring later in the Wiki, e.g., a reviewer, will be able to tell at a
> glance if a docstring is non-conforming).
>
> The "proper" thing to do at this point is to open up for editing in the Wiki
> the docstrings you edited elsewhere and cut-and-paste your work there.? Add
> a comment documenting what you've done, preview, if there are
> mark-up/standard compliance problems, fix them, etc., etc., and finally, if
> you regard the result as ready for review, change the status accordingly (or
> change it to being written if you save changes but don't yet regard it as
> "finished").? Obviously, all I can do is ask you to do this...
>
> DG
>
>>
>> Warren
>>
>>
>> David Goldsmith wrote:
>> > Hi, all. ?Joe asked me to prepare this, and I thought it might be of
>> > "universal" interest to those working on the docs. ?Following each
>> > milestone is the number of docstrings therein needing editing
>> > attention, i.e., in either the "Needs editing" or the "Being Written"
>> > state (based solely on their background color), as of today, May 4,
>> > 2010.
>> >
>> > All docstring from http://docs.scipy.org/scipy/docs/. 2584
>> >
>> > Milestones/Milestones_1
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_1/> Cluster,
>> > Constants 54
>> >
>> > Milestones/Milestones_2
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_2/> FFT, Integration
>> > 58
>> >
>> > Milestones/Milestones_3
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_3/> Interpolation 77
>> >
>> > Milestones/Milestones_4
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_4/> Input / Output
>> > 254 (most in io.matlab)
>> >
>> > Milestones/Milestones_5
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_5/> Blas, Linear
>> > Algebra 130
>> >
>> > Milestones/Milestones_6
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_6/> Max. Entropy,
>> > Misc., Image Manip. 173
>> >
>> > Milestones/Milestones_7
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_7/> Ortho. dist.
>> > regr., Optimization 100
>> >
>> > Milestones/Milestones_8
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_8/> Signal
>> > processing 119
>> >
>> > Milestones/Milestones_9
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_9/> Sparse Matrices
>> > 325
>> >
>> > Milestones/Milestones_10
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_10/> Spatial
>> > Algorithms., Special funcs. 266
>> >
>> > Milestones/Milestones_11
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_11/> Statistical
>> > functions 473
>> >
>> > Milestones/Milestones_12
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_12/> Image Array
>> > Manipulation, Convolution 47
>> >
>> > Milestones/Milestones_13
>> > <http://docs.scipy.org/scipy/Milestones/Milestones_13/> C/C++
>> > Integration 508
>> >
>> >
>> > FWIW,
>> >
>> > DG
>> >
>> > --
>> > Mathematician: noun, someone who disavows certainty when their
>> > uncertainty set is non-empty, even if that set has measure zero.
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From warren.weckesser at enthought.com  Wed May  5 06:23:31 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 05 May 2010 05:23:31 -0500
Subject: [SciPy-Dev] Request for scipy doc editor privileges
Message-ID: <4BE14723.5000901@enthought.com>

Can I (user account "warren") get edit privileges for the SciPy 
documentation editor?  Thanks.

Warren



From gael.varoquaux at normalesup.org  Wed May  5 06:26:07 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Wed, 5 May 2010 12:26:07 +0200
Subject: [SciPy-Dev] Request for scipy doc editor privileges
In-Reply-To: <4BE14723.5000901@enthought.com>
References: <4BE14723.5000901@enthought.com>
Message-ID: <20100505102607.GB31194@phare.normalesup.org>

On Wed, May 05, 2010 at 05:23:31AM -0500, Warren Weckesser wrote:
> Can I (user account "warren") get edit privileges for the SciPy 
> documentation editor?  Thanks.

Sure, ... Done.

Ga?l


From ralf.gommers at googlemail.com  Wed May  5 07:58:50 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 5 May 2010 19:58:50 +0800
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <r2y1cd32cbb1005041837k916bd546wad7eafbdc4bf4db0@mail.gmail.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
	<4BE0B617.2070200@enthought.com>
	<u2i45d1ab481005041755kfe83aec6r881f0d8767834a26@mail.gmail.com>
	<r2y1cd32cbb1005041837k916bd546wad7eafbdc4bf4db0@mail.gmail.com>
Message-ID: <k2mdde7764a1005050458x75b2c98dw6ac4cb4d6d1efc14@mail.gmail.com>

On Wed, May 5, 2010 at 9:37 AM, <josef.pktd at gmail.com> wrote:

> On Tue, May 4, 2010 at 8:55 PM, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
> > On Tue, May 4, 2010 at 5:04 PM, Warren Weckesser
> > <warren.weckesser at enthought.com> wrote:
> >>
> >> Is there an explanation somewhere of the connection between the
> >> docstrings in the source and the docstrings visible at docs.scipy.org?
>

In a bunch of mailing list posts only I'm afraid. Time to write that down
somewhere. Basically, changes made in svn propagate to the wiki every day,
and get either merged automatically or end up on the Merge page if there's a
conflict. The other way around merging is manual, the procedure is explained
in HOWTO_MERGE_WIKI_DOCS.txt under numpy/doc/. Before merging back these
should be reviewed from the Patch wiki page (you'd need to ask for rights
again to do that, not the same as edit rights).

For fixing basic typos etc. it is probably more convenient for you to do
that in svn, but as David G. pointed out it'd be good to have significant
changes/additions done in the wiki, then it's much more visible what the
history for that docstring was and its current status.

That's it in a nutshell. Wiki dev site and issues are at
http://code.google.com/p/pydocweb/.


> >> I've made an assortment of changes (via svn) in scipy.linalg and
> >> scipy.signal, including the module-level docstrings, but I don't see the
> >> changes on the web page.  For example,
> >>    http://docs.scipy.org/scipy/docs/scipy-docs/linalg.rst/
> >> is not up to date.
>

This is strange, seems to be a bug. Maybe the wiki server refuses to pull
from svn ATM or something like that.


>
>  I don't know why this doesn't indicate a conflict:
> http://docs.scipy.org/scipy/docs/scipy-docs/signal.rst/
>
> That looks fine, just a few changes on top of what's in svn.


> step2 is in source, but doesn't show in edit, nor in  "Diff to SVN"
> changes that were made in the doc editor are there
>
> step2 is not in the doceditor according to a search
>

step2 was added less than 2 days ago, changes can take that amount of time
to propagate.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100505/3b822149/attachment.html>

From josef.pktd at gmail.com  Wed May  5 08:54:55 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Wed, 5 May 2010 08:54:55 -0400
Subject: [SciPy-Dev] "Census" of scipy docstrings needing editing
	attention
In-Reply-To: <k2mdde7764a1005050458x75b2c98dw6ac4cb4d6d1efc14@mail.gmail.com>
References: <i2y45d1ab481005041554u27e4d392s40aee9de96c856ea@mail.gmail.com>
	<4BE0B617.2070200@enthought.com>
	<u2i45d1ab481005041755kfe83aec6r881f0d8767834a26@mail.gmail.com>
	<r2y1cd32cbb1005041837k916bd546wad7eafbdc4bf4db0@mail.gmail.com>
	<k2mdde7764a1005050458x75b2c98dw6ac4cb4d6d1efc14@mail.gmail.com>
Message-ID: <w2p1cd32cbb1005050554n27f0ad3ap413a5cd4901c2f87@mail.gmail.com>

On Wed, May 5, 2010 at 7:58 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Wed, May 5, 2010 at 9:37 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Tue, May 4, 2010 at 8:55 PM, David Goldsmith <d.l.goldsmith at gmail.com>
>> wrote:
>> > On Tue, May 4, 2010 at 5:04 PM, Warren Weckesser
>> > <warren.weckesser at enthought.com> wrote:
>> >>
>> >> Is there an explanation somewhere of the connection between the
>> >> docstrings in the source and the docstrings visible at docs.scipy.org?
>
> In a bunch of mailing list posts only I'm afraid. Time to write that down
> somewhere. Basically, changes made in svn propagate to the wiki every day,
> and get either merged automatically or end up on the Merge page if there's a
> conflict. The other way around merging is manual, the procedure is explained
> in HOWTO_MERGE_WIKI_DOCS.txt under numpy/doc/. Before merging back these
> should be reviewed from the Patch wiki page (you'd need to ask for rights
> again to do that, not the same as edit rights).
>
> For fixing basic typos etc. it is probably more convenient for you to do
> that in svn, but as David G. pointed out it'd be good to have significant
> changes/additions done in the wiki, then it's much more visible what the
> history for that docstring was and its current status.
>
> That's it in a nutshell. Wiki dev site and issues are at
> http://code.google.com/p/pydocweb/.
>
>>
>> >> I've made an assortment of changes (via svn) in scipy.linalg and
>> >> scipy.signal, including the module-level docstrings, but I don't see
>> >> the
>> >> changes on the web page. ?For example,
>> >> ? ?http://docs.scipy.org/scipy/docs/scipy-docs/linalg.rst/
>> >> is not up to date.
>
> This is strange, seems to be a bug. Maybe the wiki server refuses to pull
> from svn ATM or something like that.
>
>>
>> I don't know why this doesn't indicate a conflict:
>> http://docs.scipy.org/scipy/docs/scipy-docs/signal.rst/
>>
> That looks fine, just a few changes on top of what's in svn.

It doesn't indicate the diff to the current svn, but to an old svn state
(maybe the same problem as linalg.rst)

svn:

Linear Systems
==============

.. autosummary::
   :toctree: generated/

   lti
   lsim
   lsim2
   impulse
   impulse2
   step
   step2

doceditor:

Linear Systems
==============

.. autosummary::
   :toctree: generated/

   lti
   lsim
   impulse
   step

Josef

>
>>
>> step2 is in source, but doesn't show in edit, nor in ?"Diff to SVN"
>> changes that were made in the doc editor are there
>>
>> step2 is not in the doceditor according to a search
>
> step2 was added less than 2 days ago, changes can take that amount of time
> to propagate.
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Sat May  8 05:27:09 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 8 May 2010 17:27:09 +0800
Subject: [SciPy-Dev] request for Trac permissions
Message-ID: <l2wdde7764a1005080227y32fe045ej34b3daf6ed39b1b2@mail.gmail.com>

Hi, can I get permission to close tickets on scipy/numpy Trac?

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100508/b2c40fcd/attachment.html>

From pav at iki.fi  Sat May  8 06:09:37 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 8 May 2010 10:09:37 +0000 (UTC)
Subject: [SciPy-Dev] request for Trac permissions
References: <l2wdde7764a1005080227y32fe045ej34b3daf6ed39b1b2@mail.gmail.com>
Message-ID: <hs3d91$bmp$1@dough.gmane.org>

Sat, 08 May 2010 17:27:09 +0800, Ralf Gommers wrote:
> Hi, can I get permission to close tickets on scipy/numpy Trac?

Granted.

-- 
Pauli Virtanen



From ralf.gommers at googlemail.com  Sat May  8 09:37:32 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 8 May 2010 21:37:32 +0800
Subject: [SciPy-Dev] doc wiki not updating
Message-ID: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>

The doc wiki has not been updating for a while. It does have the latest svn
source, but new objects or changes to existing docstrings are not appearing.
Maybe it's a build issue?

Examples:
new object, step2 in signal.ltisys.lti:
http://docs.scipy.org/scipy/docs/scipy.signal.ltisys.lti/
existing objects:
http://docs.scipy.org/scipy/docs/scipy.signal.ltisys.lti.step/
http://docs.scipy.org/scipy/docs/scipy.stats.distributions.rv_discrete/

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100508/6f7bd723/attachment.html>

From pav at iki.fi  Sat May  8 11:06:04 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Sat, 8 May 2010 15:06:04 +0000 (UTC)
Subject: [SciPy-Dev] doc wiki not updating
References: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>
Message-ID: <hs3uks$urr$1@dough.gmane.org>

Sat, 08 May 2010 21:37:32 +0800, Ralf Gommers wrote:
> The doc wiki has not been updating for a while. It does have the latest
> svn source, but new objects or changes to existing docstrings are not
> appearing. Maybe it's a build issue?

Yes, current Scipy trunk did not work on Python 2.4, due to some Python 
2.5/2.6-isms. Should be fixed now.

-- 
Pauli Virtanen



From ralf.gommers at googlemail.com  Sat May  8 11:15:47 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 8 May 2010 23:15:47 +0800
Subject: [SciPy-Dev] doc wiki not updating
In-Reply-To: <hs3uks$urr$1@dough.gmane.org>
References: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>
	<hs3uks$urr$1@dough.gmane.org>
Message-ID: <w2vdde7764a1005080815oa9c6888ctc6bbd318dc43ae50@mail.gmail.com>

On Sat, May 8, 2010 at 11:06 PM, Pauli Virtanen <pav at iki.fi> wrote:

> Sat, 08 May 2010 21:37:32 +0800, Ralf Gommers wrote:
> > The doc wiki has not been updating for a while. It does have the latest
> > svn source, but new objects or changes to existing docstrings are not
> > appearing. Maybe it's a build issue?
>
> Yes, current Scipy trunk did not work on Python 2.4, due to some Python
> 2.5/2.6-isms. Should be fixed now.
>
> Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100508/44393626/attachment.html>

From warren.weckesser at enthought.com  Mon May 10 00:59:51 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 09 May 2010 23:59:51 -0500
Subject: [SciPy-Dev] "Generate patch" not working?
Message-ID: <4BE792C7.8090504@enthought.com>

If I go here:
   http://docs.scipy.org/scipy/patch/
then select a couple files (e.g. scipy.signal.ltisys.lsim and 
scipy.signal.ltisys.lsim2) and click on "Generate patch", I get the 
following errors:

Traceback (most recent call last):
  File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
1451, in ?
    if __name__ == "__main__": main()
  File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
82, in main
    cmd(args)
  File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
558, in cmd_patch
    doc_old = Documentation.load(open(args[0], 'r'))
  File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
1155, in load
    raise IOError("Failed to parse XML tree from %s" % stream.name)
IOError: Failed to parse XML tree from 
/home/docserver/pydocweb-data/modules/base-docsscipyorgscipy.xml


Am I doing something wrong, or is the doc server busted?

Warren



From warren.weckesser at enthought.com  Mon May 10 01:25:09 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 10 May 2010 00:25:09 -0500
Subject: [SciPy-Dev] "Generate patch" not working?
In-Reply-To: <4BE792C7.8090504@enthought.com>
References: <4BE792C7.8090504@enthought.com>
Message-ID: <4BE798B5.6040909@enthought.com>

I forgot that Ralf said you need additional rights (beyond edit rights) 
for merging wiki docs back to svn, so that might be the cause of the 
problem.

Warren

Warren Weckesser wrote:
> If I go here:
>    http://docs.scipy.org/scipy/patch/
> then select a couple files (e.g. scipy.signal.ltisys.lsim and 
> scipy.signal.ltisys.lsim2) and click on "Generate patch", I get the 
> following errors:
>
> Traceback (most recent call last):
>   File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
> 1451, in ?
>     if __name__ == "__main__": main()
>   File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
> 82, in main
>     cmd(args)
>   File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
> 558, in cmd_patch
>     doc_old = Documentation.load(open(args[0], 'r'))
>   File "/home/docserver/pydocweb/docweb/../scripts/pydoc-tool.py", line 
> 1155, in load
>     raise IOError("Failed to parse XML tree from %s" % stream.name)
> IOError: Failed to parse XML tree from 
> /home/docserver/pydocweb-data/modules/base-docsscipyorgscipy.xml
>
>
> Am I doing something wrong, or is the doc server busted?
>
> Warren
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From scott.sinclair.za at gmail.com  Mon May 10 02:22:09 2010
From: scott.sinclair.za at gmail.com (Scott Sinclair)
Date: Mon, 10 May 2010 08:22:09 +0200
Subject: [SciPy-Dev] "Generate patch" not working?
In-Reply-To: <4BE798B5.6040909@enthought.com>
References: <4BE792C7.8090504@enthought.com> <4BE798B5.6040909@enthought.com>
Message-ID: <AANLkTik0uLGKQfqk2SoNlgIjioiXOlLNSYZ4xSPRG9ot@mail.gmail.com>

>On 10 May 2010 07:25, Warren Weckesser <warren.weckesser at enthought.com> wrote:
> I forgot that Ralf said you need additional rights (beyond edit rights)
> for merging wiki docs back to svn, so that might be the cause of the
> problem.

Something is broken. Generating patches doesn't require any rights,
see http://docs.scipy.org/numpy/patch/

Merging the generated patches to svn would require svn commit rights.

Cheers,
Scott


From ralf.gommers at googlemail.com  Mon May 10 05:37:23 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 10 May 2010 17:37:23 +0800
Subject: [SciPy-Dev] doc wiki not updating
In-Reply-To: <w2vdde7764a1005080815oa9c6888ctc6bbd318dc43ae50@mail.gmail.com>
References: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>
	<hs3uks$urr$1@dough.gmane.org>
	<w2vdde7764a1005080815oa9c6888ctc6bbd318dc43ae50@mail.gmail.com>
Message-ID: <AANLkTinpNHOk8igEnH7waL2ZLybYtlIxY2z2Ah9Fbshq@mail.gmail.com>

On Sat, May 8, 2010 at 11:15 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Sat, May 8, 2010 at 11:06 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
>> Sat, 08 May 2010 21:37:32 +0800, Ralf Gommers wrote:
>> > The doc wiki has not been updating for a while. It does have the latest
>> > svn source, but new objects or changes to existing docstrings are not
>> > appearing. Maybe it's a build issue?
>>
>> Yes, current Scipy trunk did not work on Python 2.4, due to some Python
>> 2.5/2.6-isms. Should be fixed now.
>>
>> Thanks!
>

It's still not updating though. And Warren just reported that patch
generation is also broken. Looks like it needs some TLC.

Ra;f
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100510/8e59d4ed/attachment.html>

From pav at iki.fi  Tue May 11 14:50:18 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Tue, 11 May 2010 18:50:18 +0000 (UTC)
Subject: [SciPy-Dev] scipy.integrate segfault,
 refcount-related (Py2.4)? [Re: doc wiki not updating]
References: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>
	<hs3uks$urr$1@dough.gmane.org>
	<w2vdde7764a1005080815oa9c6888ctc6bbd318dc43ae50@mail.gmail.com>
	<AANLkTinpNHOk8igEnH7waL2ZLybYtlIxY2z2Ah9Fbshq@mail.gmail.com>
Message-ID: <hsc8ta$uvq$1@dough.gmane.org>

Hi,

Any ideas about this, ie. can someone with Python 2.4 reproduce it? 
Worksforme on Python 2.4.6.

It's currently blocking the Scipy doc wiki from updating, so it would be 
nice to have it fixed :/

Smells like a refcount bug somewhere in Numpy or scipy.integrate. Might 
even be a bug in Python itself. 

Python 2.4.3 (#1, Jan 21 2009, 01:11:33) 
[GCC 4.1.2 20071124 (Red Hat 4.1.2-42)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy, scipy, gc
>>> numpy.__version__
'2.0.0.dev8404'
>>> scipy.__version__
'0.8.0.dev5623'
>>> import scipy.integrate
>>> gc.collect()
python: Modules/gcmodule.c:275: visit_decref: Assertion `gc->gc.gc_refs !
= 0' failed.

Program received signal SIGABRT, Aborted.
0x0000003238430215 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003238430215 in raise () from /lib64/libc.so.6
#1  0x0000003238431cc0 in abort () from /lib64/libc.so.6
#2  0x0000003238429696 in __assert_fail () from /lib64/libc.so.6
#3  0x0000003c2e0b9c5c in ?? () from /usr/lib64/libpython2.4.so.1.0
#4  0x0000003c2e05a89d in ?? () from /usr/lib64/libpython2.4.so.1.0
#5  0x0000003c2e0ba157 in ?? () from /usr/lib64/libpython2.4.so.1.0
#6  0x0000003c2e0babf4 in ?? () from /usr/lib64/libpython2.4.so.1.0
#7  0x0000003c2e094747 in PyEval_EvalFrame ()
   from /usr/lib64/libpython2.4.so.1.0
#8  0x0000003c2e0958a5 in PyEval_EvalCodeEx ()
   from /usr/lib64/libpython2.4.so.1.0
#9  0x0000003c2e0958f2 in PyEval_EvalCode ()
   from /usr/lib64/libpython2.4.so.1.0
#10 0x0000003c2e0b1f29 in ?? () from /usr/lib64/libpython2.4.so.1.0
#11 0x0000003c2e0b37e7 in PyRun_InteractiveOneFlags ()
   from /usr/lib64/libpython2.4.so.1.0
#12 0x0000003c2e0b38de in PyRun_InteractiveLoopFlags ()
   from /usr/lib64/libpython2.4.so.1.0
#13 0x0000003c2e0b39ec in PyRun_AnyFileExFlags ()
   from /usr/lib64/libpython2.4.so.1.0
#14 0x0000003c2e0b980d in Py_Main () from /usr/lib64/libpython2.4.so.1.0
#15 0x000000323841d974 in __libc_start_main () from /lib64/libc.so.6
#16 0x0000000000400629 in _start ()
(gdb) q

(Yeah, debugging symbols missing ATM, but I guess the backtrace would be 
of little help anyway since the crash is nonlocal.)

Mon, 10 May 2010 17:37:23 +0800, Ralf Gommers wrote:
[scipy doc wiki]
> It's still not updating though. And Warren just reported that patch
> generation is also broken. Looks like it needs some TLC.



From d.l.goldsmith at gmail.com  Tue May 11 23:11:52 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 11 May 2010 20:11:52 -0700
Subject: [SciPy-Dev] Milestones link at the top of the SciPy Wiki
Message-ID: <AANLkTin735wEGiTqa72EV-MzMhYP0mDT9TS_3RaiXPzf@mail.gmail.com>

Points to the NumPy Wiki Milestones page.

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100511/6d830b92/attachment.html>

From pav at iki.fi  Thu May 13 07:15:04 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 13 May 2010 11:15:04 +0000 (UTC)
Subject: [SciPy-Dev] doc wiki not updating
References: <r2jdde7764a1005080637j1bfe714bx6135b1daca406aef@mail.gmail.com>
	<hs3uks$urr$1@dough.gmane.org>
	<w2vdde7764a1005080815oa9c6888ctc6bbd318dc43ae50@mail.gmail.com>
	<AANLkTinpNHOk8igEnH7waL2ZLybYtlIxY2z2Ah9Fbshq@mail.gmail.com>
Message-ID: <hsgmvo$hh3$1@dough.gmane.org>

Mon, 10 May 2010 17:37:23 +0800, Ralf Gommers wrote:
[clip: doc wiki]
> It's still not updating though. And Warren just reported that patch
> generation is also broken. Looks like it needs some TLC.

Fixed. 'twas a double-decref bug in Numpy.

	Pauli



From pav at iki.fi  Thu May 13 07:25:33 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 13 May 2010 11:25:33 +0000 (UTC)
Subject: [SciPy-Dev] io -> npyio move: doc wiki update
References: <i2odde7764a1004110243oc9b5d698zfb3791ef9310f27@mail.gmail.com>
Message-ID: <hsgnjd$hh3$2@dough.gmane.org>

Sun, 11 Apr 2010 17:43:36 +0800, Ralf Gommers wrote:
> Here's a reminder that after the rename of numpy.io, the pages and
> history of all its objects in the doc wiki need to be carried over.

Moved, thanks!

	Pauli



From gael.varoquaux at normalesup.org  Thu May 13 09:31:24 2010
From: gael.varoquaux at normalesup.org (=?ISO-8859-1?Q?Ga=EBl_Varoquaux?=)
Date: Thu, 13 May 2010 15:31:24 +0200
Subject: [SciPy-Dev] EuroScipy is finally open for registration
Message-ID: <AANLkTimCRD6r1JOzl6kMbktu5jmBZv8Lm_0y0IzmNUO2@mail.gmail.com>

The registration for
EuroScipy<http://www.euroscipy.org//conference/euroscipy2010>is
finally open.

To register, go to the
website<http://www.euroscipy.org//conference/euroscipy2010>,
create an account, and you will see a *?register to the conference?* button
on the left. Follow it to a page which presents a *?shoping cart?*. Simply
submitting this information registers you to the conference, and on the left
of the website, the button will now display *?You are registered for the
conference?*.

The registration fee is 50 euros for the conference, and 50 euros for the
tutorial. Right now there is no payment system: you will be contacted later
(in a week) with instructions for paying.

We apologize for such a late set up. We do realize this has come as an
inconvenience to people.

*Do not wait to register: the number of people we can host is limited.*
An exciting program Tutorials: from beginners to experts

We have two tutorial tracks:

   - *Introductory tutorial* <http://www.euroscipy.org/track/871>: to get
   you to speed on scientific programming with Python.
   - *Advanced tutorial* <http://www.euroscipy.org/track/872>: experts
   sharing their knowledge on specific techniques and libraries.

   We are very fortunate to have a top notch set of presenters.

Scientific track: doing new science in Python

Although the abstract submission is not yet over, We can say that we are
going to have a rich set of talks, looking at the current submissions. In
addition to the contributed talks, we have:

   - *Keynote speakers* <http://www.euroscipy.org/conference/euroscipy2010>:
   Hans Petter Langtangen and Konrard Hinsen, two major player of scientific
   computing in Python.
   - *Lightning talks* <http://www.euroscipy.org/talk/937>: one hour will be
   open for people to come up and present in a flash an interesting project.

Publishing papers

We are talking with the editors of a major scientific computing journal, and
the odds are quite high that we will be able to publish a special issue on
scientific computing in Python based on the proceedings of the conference.
The papers will undergo peer-review independently from the conference, to
ensure high quality of the final publication.
Call for papers

Abstract submission is still open, though not for long. We are soliciting
contributions on scientific libraries and tools developed with Python and on
scientific or engineering achievements using Python. These include
applications, teaching, future development directions, and current research.
See the call for
papers<http://www.euroscipy.org/card/euroscipy2010_call_for_papers>
.

*We are very much looking forward to passionate discussions about Python in
science in Paris*

*Nicolas Chauvat and Ga?l Varoquaux*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100513/982201b2/attachment.html>

From cimrman3 at ntc.zcu.cz  Thu May 13 10:11:40 2010
From: cimrman3 at ntc.zcu.cz (Robert Cimrman)
Date: Thu, 13 May 2010 16:11:40 +0200
Subject: [SciPy-Dev] ANN: SfePy 2010.2
Message-ID: <4BEC089C.1000609@ntc.zcu.cz>

(resending - the Monday post did not get through)

I am pleased to announce release 2010.2 of SfePy.

Description
-----------

SfePy (simple finite elements in Python) is a software for solving systems of
coupled partial differential equations by the finite element method. The code
is based on NumPy and SciPy packages. It is distributed under the new BSD
license.

Mailing lists, issue tracking, git repository: http://sfepy.org
Home page: http://sfepy.kme.zcu.cz

Documentation: http://docs.sfepy.org/doc

Highlights of this release
--------------------------
- significantly updated documentation
- new wiki pages:
   - SfePy Primer [1]
   - How to use Salome for generating meshes [2]

[1] http://code.google.com/p/sfepy/wiki/Primer
[2] http://code.google.com/p/sfepy/wiki/ExampleUsingSalomeWithSfePy

Major improvements
------------------
Apart from many bug-fixes, let us mention:
- new mesh readers (MED (Salome, PythonOCC), Gambit NEU, UserMeshIO)
- mechanics:
   - ElasticConstants class - conversion formulas for elastic constants
   - StressTransform class to convert various stress tensors
   - basic tensor transformations
- new examples:
   - usage of functions to define various parameter
   - usage of probes
- new tests and many new terms

For more information on this release, see
http://sfepy.googlecode.com/svn/web/releases/2010.2_RELEASE_NOTES.txt
(full release notes, rather long).

Best regards,
Robert Cimrman and Contributors (*)

(*) Contributors to this release (alphabetical order):

Vladim?r Luke?, Andre Smit, Logan Sorenson, Zuzana Z?horov?


From josef.pktd at gmail.com  Thu May 13 14:13:11 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 13 May 2010 14:13:11 -0400
Subject: [SciPy-Dev] distribution docstring generation
Message-ID: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>

It works, and I merged the docstrings and did some basic editing in
rv_continuous and rv_discrete.

the template version seems to have problems with %(shapes)s in the
Parameter list  when shapes is empty,
e.g http://docs.scipy.org/scipy/docs/scipy.stats.maxwell/

The instance descriptions seems to allow editing, but only the class
docstring should be edited
e.g. http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/

Josef


From d.l.goldsmith at gmail.com  Thu May 13 14:49:02 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 13 May 2010 11:49:02 -0700
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
Message-ID: <AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>

On Thu, May 13, 2010 at 11:13 AM, <josef.pktd at gmail.com> wrote:

> It works, and I merged the docstrings and did some basic editing in
> rv_continuous and rv_discrete.
>
> the template version seems to have problems with %(shapes)s in the
> Parameter list  when shapes is empty,
> e.g http://docs.scipy.org/scipy/docs/scipy.stats.maxwell/
>
> The instance descriptions seems to allow editing, but only the class
> docstring should be edited
> e.g.
> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
>

Would you go so far as to characterize this as a bug?

DG


>
> Josef
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100513/05cdce1c/attachment.html>

From josef.pktd at gmail.com  Thu May 13 15:34:50 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 13 May 2010 15:34:50 -0400
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
Message-ID: <AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>

On Thu, May 13, 2010 at 2:49 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Thu, May 13, 2010 at 11:13 AM, <josef.pktd at gmail.com> wrote:
>>
>> It works, and I merged the docstrings and did some basic editing in
>> rv_continuous and rv_discrete.
>>
>> the template version seems to have problems with %(shapes)s in the
>> Parameter list ?when shapes is empty,
>> e.g http://docs.scipy.org/scipy/docs/scipy.stats.maxwell/
>>
>> The instance descriptions seems to allow editing, but only the class
>> docstring should be edited
>> e.g.
>> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
>
> Would you go so far as to characterize this as a bug?

Bug, undesired feature or feature request ?
I have no idea whether or how the doceditor can blacklist a function
(or class instance) so it cannot be edited or so it redirects to the
correct location.

The templating system is new for the distributions, so I'm also not
sure yet how it behaves everywhere.

I edited Poisson just to check
http://docs.scipy.org/scipy/docs/scipy.stats.poisson/

I could save the edit, but I have no idea where it would be stored.
And it's not supposed to be directly edited.

Josef


>
> DG
>
>>
>> Josef
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Fri May 14 11:26:09 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 14 May 2010 23:26:09 +0800
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
Message-ID: <AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>

On Fri, May 14, 2010 at 3:34 AM, <josef.pktd at gmail.com> wrote:

> On Thu, May 13, 2010 at 2:49 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > On Thu, May 13, 2010 at 11:13 AM, <josef.pktd at gmail.com> wrote:
> >>
> >> It works, and I merged the docstrings and did some basic editing in
> >> rv_continuous and rv_discrete.
> >>
> >> the template version seems to have problems with %(shapes)s in the
> >> Parameter list  when shapes is empty,
> >> e.g http://docs.scipy.org/scipy/docs/scipy.stats.maxwell/
>

Should be fixed in r6390.


> >>
> >> The instance descriptions seems to allow editing, but only the class
> >> docstring should be edited
> >> e.g.
> >> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
> >
> > Would you go so far as to characterize this as a bug?
>
> Bug, undesired feature or feature request ?
> I have no idea whether or how the doceditor can blacklist a function
> (or class instance) so it cannot be edited or so it redirects to the
> correct location.
>

Don't know either, but it would be very useful to be able to 'lock' pages.
Since I don't think that's possible right now, maybe a capitalized note on
each page is in order.


> The templating system is new for the distributions, so I'm also not
> sure yet how it behaves everywhere.
>
> I edited Poisson just to check
> http://docs.scipy.org/scipy/docs/scipy.stats.poisson/
>
> I could save the edit, but I have no idea where it would be stored.
> And it's not supposed to be directly edited.
>

It's stored in the wiki vcs. When a patch from it would be generated, it
wouldn't work anyway since these distributions are class instances. In this
respect nothing changed, the old template system could also not be edited in
the wiki.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100514/2e9437d8/attachment.html>

From josef.pktd at gmail.com  Fri May 14 11:58:59 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Fri, 14 May 2010 11:58:59 -0400
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
Message-ID: <AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>

On Fri, May 14, 2010 at 11:26 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Fri, May 14, 2010 at 3:34 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, May 13, 2010 at 2:49 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>> > On Thu, May 13, 2010 at 11:13 AM, <josef.pktd at gmail.com> wrote:
>> >>
>> >> It works, and I merged the docstrings and did some basic editing in
>> >> rv_continuous and rv_discrete.
>> >>
>> >> the template version seems to have problems with %(shapes)s in the
>> >> Parameter list ?when shapes is empty,
>> >> e.g http://docs.scipy.org/scipy/docs/scipy.stats.maxwell/
>
> Should be fixed in r6390.
>
>>
>> >>
>> >> The instance descriptions seems to allow editing, but only the class
>> >> docstring should be edited
>> >> e.g.
>> >> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
>> >
>> > Would you go so far as to characterize this as a bug?
>>
>> Bug, undesired feature or feature request ?
>> I have no idea whether or how the doceditor can blacklist a function
>> (or class instance) so it cannot be edited or so it redirects to the
>> correct location.
>
> Don't know either, but it would be very useful to be able to 'lock' pages.
> Since I don't think that's possible right now, maybe a capitalized note on
> each page is in order.

Is there a way to add a note?
I also thought, setting all of the distribution instances to
"unimportant" would be useful as a short run measure, but there are
too many of them for me to do page-by-page by hand

One more alternative, "unimportant" is the lowest category for page
editing, maybe it is possible to add a category "DO NOT EDIT"  if we
cannot look the page down.

Josef


>>
>> The templating system is new for the distributions, so I'm also not
>> sure yet how it behaves everywhere.
>>
>> I edited Poisson just to check
>> http://docs.scipy.org/scipy/docs/scipy.stats.poisson/
>>
>> I could save the edit, but I have no idea where it would be stored.
>> And it's not supposed to be directly edited.
>
> It's stored in the wiki vcs. When a patch from it would be generated, it
> wouldn't work anyway since these distributions are class instances. In this
> respect nothing changed, the old template system could also not be edited in
> the wiki.
>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Fri May 14 23:29:03 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 15 May 2010 11:29:03 +0800
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
	<AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
Message-ID: <AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>

On Fri, May 14, 2010 at 11:58 PM, <josef.pktd at gmail.com> wrote:

> On Fri, May 14, 2010 at 11:26 AM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> >> Bug, undesired feature or feature request ?
> >> I have no idea whether or how the doceditor can blacklist a function
> >> (or class instance) so it cannot be edited or so it redirects to the
> >> correct location.
> >
> > Don't know either, but it would be very useful to be able to 'lock'
> pages.
> > Since I don't think that's possible right now, maybe a capitalized note
> on
> > each page is in order.
>
> Is there a way to add a note?
>

I meant in the comment field.


> I also thought, setting all of the distribution instances to
> "unimportant" would be useful as a short run measure, but there are
> too many of them for me to do page-by-page by hand
>
> One more alternative, "unimportant" is the lowest category for page
> editing, maybe it is possible to add a category "DO NOT EDIT"  if we
> cannot look the page down.
>
> Either one of the above would help. I guess Pauli has to decide what is
easiest.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100515/131d5ef3/attachment.html>

From ralf.gommers at googlemail.com  Sat May 15 00:04:54 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 15 May 2010 12:04:54 +0800
Subject: [SciPy-Dev] test output - io and stats
Message-ID: <AANLkTinz_XtOOecPsOrycZGOgOqCaDtupfuTFPYiPTPp@mail.gmail.com>

Hi,

In two weeks we'll create the 0.8 branch, and it would be good to have the
test output cleaned up before then. It is very noisy, the main offenders are
the io and stats modules. Output pasted below, most of it is deprecations
and future warnings.

Matthew and Josef, will you have time for some spring cleaning in the next
few weeks?

Thanks,
Ralf



Running unit tests for scipy
NumPy version 1.4.1
NumPy is installed in
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy
SciPy version 0.8.0.dev
SciPy is installed in /Users/rgommers/Code/scipy/scipy
Python version 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) [GCC 4.0.1 (Apple
Inc. build 5493)]
nose version 0.11.1
.............................................................................................................................................................................................................................................................................../Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:512:
UserWarning:
The coefficients of the spline returned have been computed as the
minimal norm least-squares solution of a (numerically) rank deficient
system (deficiency=7). If deficiency is large, the results may be
inaccurate. Deficiency may strongly depend on the value of eps.
  warnings.warn(message)
...../Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:453:
UserWarning:
The required storage space exceeds the available storage space: nxest
or nyest too small, or s too small.
The weighted least-squares spline corresponds to the current set of
knots.
  warnings.warn(message)
...........................................K..K................................................................................................................/Users/rgommers/Code/scipy/scipy/io/matlab/mio.py:190:
FutureWarning: Using oned_as default value ('column') This will change to
'row' in future versions
  oned_as=oned_as)
........................./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:435:
FutureWarning: Using oned_as default value ('column') This will change to
'row' in future versions
  mfw = MatFile5Writer(StringIO())
....../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:450:
FutureWarning: Using oned_as default value ('column') This will change to
'row' in future versions
  wtr = MatFile5Writer(sio)
../Users/rgommers/Code/scipy/scipy/io/matlab/mio.py:99: FutureWarning: Using
struct_as_record default value (False) This will change to True in future
versions
  return MatFile5Reader(byte_stream, **kwargs)
.............................../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:633:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:637:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream, squeeze_me=True)
../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:641:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream, byte_order=boc.native_code)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:645:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream, byte_order=boc.swapped_code)
../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:652:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:654:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream, chars_as_strings=False)
../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:664:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(file(estring_fname))
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:674:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:679:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(stream)
../Users/rgommers/Code/scipy/scipy/io/matlab/mio4.py:338:
DeprecationWarning: Matlab 4 files only support <=2 dimensions; future
versions of scipy will raise an error when trying to write >2D arrays to
matlab 4 format files
  DeprecationWarning,
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:699:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(file(func_eg))
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:703:
FutureWarning: Using oned_as default value ('column') This will change to
'row' in future versions
  wtr = MatFile5Writer(stream)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:709:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(file(double_eg), mat_dtype=False)
./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:712:
FutureWarning: Using struct_as_record default value (False) This will change
to True in future versions
  rdr = MatFile5Reader(file(double_eg), mat_dtype=True)
.................................................................................................................................Warning:
1000000 bytes requested, 20 bytes read.
./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `write_array` is deprecated!

This function is replaced by numpy.savetxt which allows the same
functionality
through a different syntax.

  warnings.warn(depdoc, DeprecationWarning)
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `read_array` is deprecated!

The functionality of read_array is in numpy.loadtxt which allows the same
functionality using different syntax.

  warnings.warn(depdoc, DeprecationWarning)
...........................................Exception AttributeError:
"'netcdf_file' object has no attribute 'mode'" in <bound method
netcdf_file.close of <scipy.io.netcdf.netcdf_file object at 0x56c9750>>
ignored
............/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `npfile` is deprecated!

You can achieve the same effect as using npfile using numpy.save and
numpy.load.

You can use memory-mapped arrays and data-types to map out a
file format for direct manipulation in NumPy.

  warnings.warn(depdoc, DeprecationWarning)
........./Users/rgommers/Code/scipy/scipy/io/wavfile.py:20: WavFileWarning:
Unfamiliar format bytes
  warnings.warn("Unfamiliar format bytes", WavFileWarning)
/Users/rgommers/Code/scipy/scipy/io/wavfile.py:92: WavFileWarning: chunk not
understood
  warnings.warn("chunk not understood", WavFileWarning)
...[14 36 39 56 57] [14 36 39 56 57]
.[[ 26  10]
 [ 42 104]
 [  1 102]
 [ 92   5]
 [ 72  95]] [[ 26  10]
 [ 42 104]
 [  1 102]
 [ 92   5]
 [ 72  95]]
.[[  9  82   2  84  43]
 [122  86  18  41  79]
 [ 95  99  69 100  40]
 [126   9 124  38  65]
 [ 59  80  90 122  85]] [[  9  82   2  84  43]
 [122  86  18  41  79]
 [ 95  99  69 100  40]
 [126   9 124  38  65]
 [ 59  80  90 122  85]]
.[ 16  17  89  63 123] [ 16  17  89  63 123]
.[[ 63 113]
 [ 41  36]
 [ 44  31]
 [ 76   2]
 [127  47]] [[ 63 113]
 [ 41  36]
 [ 44  31]
 [ 76   2]
 [127  47]]
.[[ 36   9  59 117 116]
 [  4  75  11 106  63]
 [ 79  82 126  55 117]
 [ 79  29   1  24  35]
 [ 29  14 107  79  86]] [[ 36   9  59 117 116]
 [  4  75  11 106  63]
 [ 79  82 126  55 117]
 [ 79  29   1  24  35]
 [ 29  14 107  79  86]]
.[ 54  42  52 115  88] [ 54  42  52 115  88]
.[[ 27  30]
 [ 47  77]
 [ 91  26]
 [ 74 123]
 [ 73  86]] [[ 27  30]
 [ 47  77]
 [ 91  26]
 [ 74 123]
 [ 73  86]]
.[[  5  99  21  83  34]
 [124  47  65  29 127]
 [121   2  53  33  55]
 [  6 124  25  98  97]
 [ 59  57  16 110  83]] [[  5  99  21  83  34]
 [124  47  65  29 127]
 [121   2  53  33  55]
 [  6 124  25  98  97]
 [ 59  57  16 110  83]]
.[ 6 20 32 27 92] [ 6 20 32 27 92]
.[[ 80 108]
 [ 55  65]
 [ 28  57]
 [ 14 112]
 [  9  29]] [[ 80 108]
 [ 55  65]
 [ 28  57]
 [ 14 112]
 [  9  29]]
.[[ 41 126  18  66  47]
 [ 68  59  90  71  82]
 [ 55  88  48  64 112]
 [ 59  19  86  52 117]
 [  8  21  14  59  99]] [[ 41 126  18  66  47]
 [ 68  59  90  71  82]
 [ 55  88  48  64 112]
 [ 59  19  86  52 117]
 [  8  21  14  59  99]]
.[104  76  54  96  62] [104  76  54  96  62]
.[[ 40  61]
 [112  33]
 [ 20  22]
 [ 33  68]
 [ 54  46]] [[ 40  61]
 [112  33]
 [ 20  22]
 [ 33  68]
 [ 54  46]]
.[[ 86  36  82  46 106]
 [  6 104  86  41  53]
 [ 13 110 123  70  76]
 [101  14  98  63 100]
 [ 57  23   3  13  38]] [[ 86  36  82  46 106]
 [  6 104  86  41  53]
 [ 13 110 123  70  76]
 [101  14  98  63 100]
 [ 57  23   3  13  38]]
.[ 6 17 59 54 34] [ 6 17 59 54 34]
.[[71 68]
 [42 73]
 [60 70]
 [24 11]
 [93  1]] [[71 68]
 [42 73]
 [60 70]
 [24 11]
 [93  1]]
.[[ 58   3  60  27  96]
 [ 87  55  79 117  83]
 [121 121  38  96  23]
 [  4   3  65  74  81]
 [  2 121  64  71  88]] [[ 58   3  60  27  96]
 [ 87  55  79 117  83]
 [121 121  38  96  23]
 [  4   3  65  74  81]
 [  2 121  64  71  88]]
.[111  40  36  64  39] [111  40  36  64  39]
.[[ 30 121]
 [ 38 119]
 [ 12  75]
 [109  62]
 [ 28  89]] [[ 30 121]
 [ 38 119]
 [ 12  75]
 [109  62]
 [ 28  89]]
.[[ 43  96 101  73  99]
 [ 40 119  91  13  69]
 [ 53 121  62  40  32]
 [ 92 106  37 112   9]
 [ 81  35  80  11  96]] [[ 43  96 101  73  99]
 [ 40 119  91  13  69]
 [ 53 121  62  40  32]
 [ 92 106  37 112   9]
 [ 81  35  80  11  96]]
.[105  71 115 123  51] [105  71 115 123  51]
.[[ 54  84]
 [106 124]
 [117   8]
 [  0  64]
 [ 65 100]] [[ 54  84]
 [106 124]
 [117   8]
 [  0  64]
 [ 65 100]]
.[[ 28 117 109  49  39]
 [ 74  52 106 126  97]
 [ 60  77  74  22  20]
 [ 34 110  34  61  93]
 [  2  62  22  38  57]] [[ 28 117 109  49  39]
 [ 74  52 106 126  97]
 [ 60  77  74  22  20]
 [ 34 110  34  61  93]
 [  2  62  22  38  57]]
.[ 20 112  14  33  78] [ 20 112  14  33  78]
.[[112  51]
 [ 85  88]
 [ 61  38]
 [123   6]
 [113  84]] [[112  51]
 [ 85  88]
 [ 61  38]
 [123   6]
 [113  84]]
.[[  4  49   4  89 121]
 [ 88  77  91  37  26]
 [ 79 124 107  43  90]
 [ 10  23  74  78  21]
 [122  67  96 120 127]] [[  4  49   4  89 121]
 [ 88  77  91  37  26]
 [ 79 124 107  43  90]
 [ 10  23  74  78  21]
 [122  67  96 120 127]]
.[21  8 91 95 95] [21  8 91 95 95]
.[[ 30 100]
 [  1  20]
 [ 52 112]
 [ 56  72]
 [ 39  99]] [[ 30 100]
 [  1  20]
 [ 52 112]
 [ 56  72]
 [ 39  99]]
.[[ 83  36  41 101 109]
 [ 76 119  62  33  41]
 [113  42 118 104 125]
 [ 19  59  87 101  99]
 [ 77  50  65 117 104]] [[ 83  36  41 101 109]
 [ 76 119  62  33  41]
 [113  42 118 104 125]
 [ 19  59  87 101  99]
 [ 77  50  65 117 104]]
.[ 93 126 106  60  99] [ 93 126 106  60  99]
.[[104  10]
 [100 112]
 [125  30]
 [ 59  94]
 [ 44  28]] [[104  10]
 [100 112]
 [125  30]
 [ 59  94]
 [ 44  28]]
.[[ 10 106  83 102  41]
 [ 91  93  45  87  61]
 [ 37 123  68  52  83]
 [  5   5  49 121  87]
 [ 89  59  69 111 107]] [[ 10 106  83 102  41]
 [ 91  93  45  87  61]
 [ 37 123  68  52  83]
 [  5   5  49 121  87]
 [ 89  59  69 111 107]]
.[94 71 80 50 71] [94 71 80 50 71]
.[[106  63]
 [ 63  61]
 [111  57]
 [122  86]
 [ 54  85]] [[106  63]
 [ 63  61]
 [111  57]
 [122  86]
 [ 54  85]]
.[[ 41 104 123  11 104]
 [ 18   1  97  55  20]
 [ 43   6  18  48  72]
 [ 60  45  14  17  68]
 [ 97  98  46  34  49]] [[ 41 104 123  11 104]
 [ 18   1  97  55  20]
 [ 43   6  18  48  72]
 [ 60  45  14  17  68]
 [ 97  98  46  34  49]]
.[92 75 36 25  1] [92 75 36 25  1]
.[[ 24   8]
 [ 95 111]
 [105  95]
 [ 60 123]
 [ 46  49]] [[ 24   8]
 [ 95 111]
 [105  95]
 [ 60 123]
 [ 46  49]]
.[[116   6   2  41  43]
 [ 64  43  20  36  82]
 [ 43   8  27  87  39]
 [ 14 115 121  34  49]
 [  3  49  44  72  67]] [[116   6   2  41  43]
 [ 64  43  20  36  82]
 [ 43   8  27  87  39]
 [ 14 115 121  34  49]
 [  3  49  44  72  67]]
.[ 53 116  82  51  18] [ 53 116  82  51  18]
.[[ 65  78]
 [123  17]
 [ 42  25]
 [ 20  95]
 [ 26 121]] [[ 65  78]
 [123  17]
 [ 42  25]
 [ 20  95]
 [ 26 121]]
.[[ 65  58  77  95  83]
 [ 72  49  55  60  54]
 [ 52   2  29  22   4]
 [119  66  91  99 127]
 [105  19 120  41 106]] [[ 65  58  77  95  83]
 [ 72  49  55  60  54]
 [ 52   2  29  22   4]
 [119  66  91  99 127]
 [105  19 120  41 106]]
.[ 68 100   1  21  41] [ 68 100   1  21  41]
.[[ 87  86]
 [ 86 112]
 [ 92  39]
 [ 33 101]
 [ 70 116]] [[ 87  86]
 [ 86 112]
 [ 92  39]
 [ 33 101]
 [ 70 116]]
.[[  3  45 106  58  51]
 [ 52  13  54 124  85]
 [ 36  43  45 122  86]
 [ 74 118   7  53  83]
 [ 98  53  39  78  85]] [[  3  45 106  58  51]
 [ 52  13  54 124  85]
 [ 36  43  45 122  86]
 [ 74 118   7  53  83]
 [ 98  53  39  78  85]]
.[  4  21  40  10 122] [  4  21  40  10 122]
.[[104  50]
 [ 74  68]
 [ 89  85]
 [ 46 100]
 [ 73   0]] [[104  50]
 [ 74  68]
 [ 89  85]
 [ 46 100]
 [ 73   0]]
.[[ 81  41   8  61  38]
 [ 81  85   9  80  29]
 [ 67  51  12  53  95]
 [107  73  56  63  35]
 [ 54  44  28  73  64]] [[ 81  41   8  61  38]
 [ 81  85   9  80  29]
 [ 67  51  12  53  95]
 [107  73  56  63  35]
 [ 54  44  28  73  64]]
.[ 30  89 121  95  30] [ 30  89 121  95  30]
.[[ 61  88]
 [ 97  97]
 [ 73  36]
 [127  70]
 [110  65]] [[ 61  88]
 [ 97  97]
 [ 73  36]
 [127  70]
 [110  65]]
.[[ 71 103  38  26  28]
 [ 87  23   0  43  43]
 [106 115 110  93   7]
 [ 73  24  79   1 118]
 [100 117  70  27  21]] [[ 71 103  38  26  28]
 [ 87  23   0  43  43]
 [106 115 110  93   7]
 [ 73  24  79   1 118]
 [100 117  70  27  21]]
.[ 28  44 110  14 113] [ 28  44 110  14 113]
.[[ 72  99]
 [120  15]
 [ 79  49]
 [ 49 126]
 [ 82  26]] [[ 72  99]
 [120  15]
 [ 79  49]
 [ 49 126]
 [ 82  26]]
.[[118 125  53  78 125]
 [  9  51  77 100  83]
 [109  92 123 127   6]
 [ 20 118  18  35  19]
 [ 13  96 126  84 117]] [[118 125  53  78 125]
 [  9  51  77 100  83]
 [109  92 123 127   6]
 [ 20 118  18  35  19]
 [ 13  96 126  84 117]]
.[ 56  95  85 103  23] [ 56  95  85 103  23]
.[[ 15  42]
 [ 90  17]
 [ 83   2]
 [ 59  74]
 [125  74]] [[ 15  42]
 [ 90  17]
 [ 83   2]
 [ 59  74]
 [125  74]]
.[[  3  80  60 112  91]
 [  6 101  74  31 117]
 [111  80  47  67  69]
 [  2  92  61  46  88]
 [ 81 127  44  74  15]] [[  3  80  60 112  91]
 [  6 101  74  31 117]
 [111  80  47  67  69]
 [  2  92  61  46  88]
 [ 81 127  44  74  15]]
.[40 81 89 29 77] [40 81 89 29 77]
.[[ 45  45]
 [  1  63]
 [109   7]
 [  2 121]
 [ 84   3]] [[ 45  45]
 [  1  63]
 [109   7]
 [  2 121]
 [ 84   3]]
.[[113 104 111  23  40]
 [ 91  34  78  26  36]
 [ 16  34  57   5 112]
 [ 42  28  13  88 100]
 [100  77  89  70 113]] [[113 104 111  23  40]
 [ 91  34  78  26  36]
 [ 16  34  57   5 112]
 [ 42  28  13  88 100]
 [100  77  89  70 113]]
.[ 16 107  80  96  80] [ 16 107  80  96  80]
.[[ 89  70]
 [127  78]
 [ 80  44]
 [ 11 118]
 [ 55 105]] [[ 89  70]
 [127  78]
 [ 80  44]
 [ 11 118]
 [ 55 105]]
.[[ 19  61  95  15  21]
 [ 74  42   4  72  86]
 [ 93 118  97  20  81]
 [125   4  35  40  56]
 [105  72  10  84  20]] [[ 19  61  95  15  21]
 [ 74  42   4  72  86]
 [ 93 118  97  20  81]
 [125   4  35  40  56]
 [105  72  10  84  20]]
.[ 60  93  20  10 121] [ 60  93  20  10 121]
.[[118  12]
 [ 16  70]
 [ 17 123]
 [ 28  91]
 [  4 122]] [[118  12]
 [ 16  70]
 [ 17 123]
 [ 28  91]
 [  4 122]]
.[[ 34  75  13  58   1]
 [103  94 122  44  24]
 [ 21  82  22 112   7]
 [120  78  51  37  96]
 [ 42  16   7  86  96]] [[ 34  75  13  58   1]
 [103  94 122  44  24]
 [ 21  82  22 112   7]
 [120  78  51  37  96]
 [ 42  16   7  86  96]]
.[ 97 118  25  48  27] [ 97 118  25  48  27]
.[[ 21   0]
 [111  78]
 [  3  48]
 [ 67 118]
 [120  71]] [[ 21   0]
 [111  78]
 [  3  48]
 [ 67 118]
 [120  71]]
.[[ 75  75 117  16 110]
 [119 123   3  62  73]
 [ 68  98  56  89  43]
 [ 18  47  36  75  76]
 [  9  77  86   2  68]] [[ 75  75 117  16 110]
 [119 123   3  62  73]
 [ 68  98  56  89  43]
 [ 18  47  36  75  76]
 [  9  77  86   2  68]]
.[40 25 77  6 45] [40 25 77  6 45]
.[[104  35]
 [ 37  83]
 [108  15]
 [113  34]
 [ 60  77]] [[104  35]
 [ 37  83]
 [108  15]
 [113  34]
 [ 60  77]]
.[[  0  65 108  27 105]
 [ 63  24  31   9  70]
 [ 64  75  93  57 108]
 [  9  35  37  74  62]
 [109 127  69  89  46]] [[  0  65 108  27 105]
 [ 63  24  31   9  70]
 [ 64  75  93  57 108]
 [  9  35  37  74  62]
 [109 127  69  89  46]]
.[ 84 107  81 125  94] [ 84 107  81 125  94]
.[[  2 115]
 [120  91]
 [ 91  53]
 [ 63 109]
 [ 70  60]] [[  2 115]
 [120  91]
 [ 91  53]
 [ 63 109]
 [ 70  60]]
.[[101 106 105  84  47]
 [ 18  87 124  94  45]
 [ 64  40  27  33  75]
 [ 87 109   8 119  61]
 [ 70  82  34  47  46]] [[101 106 105  84  47]
 [ 18  87 124  94  45]
 [ 64  40  27  33  75]
 [ 87 109   8 119  61]
 [ 70  82  34  47  46]]
.[100   0  72 118  26] [100   0  72 118  26]
.[[27 42]
 [78 54]
 [ 1 88]
 [55 62]
 [49 83]] [[27 42]
 [78 54]
 [ 1 88]
 [55 62]
 [49 83]]
.[[ 70  55  21 113  61]
 [ 18 116 100  65  13]
 [126   6  68  39 109]
 [103 111  63  12 120]
 [ 13  28  84  67  82]] [[ 70  55  21 113  61]
 [ 18 116 100  65  13]
 [126   6  68  39 109]
 [103 111  63  12 120]
 [ 13  28  84  67  82]]
...............................................................................................................................................SSSSSS......SSSSSS......SSSS..............................................................S.................................................../Users/rgommers/Code/scipy/scipy/linalg/decomp_qr.py:77:
DeprecationWarning: qr econ argument will be removed after scipy 0.7. The
economy transform will then be available through the mode='economic'
argument.
  "the mode='economic' argument.", DeprecationWarning)
................................................................................................................................................................E....................................................................................................................................................
****************************************************************
WARNING: clapack module is empty
-----------
See scipy/INSTALL.txt for troubleshooting.
Notes:
* If atlas library is not found by numpy/distutils/system_info.py,
  then scipy uses flapack instead of clapack.
****************************************************************

...Result may be inaccurate, approximate err = 7.68933681286e-09
...Result may be inaccurate, approximate err = 7.27595761418e-12
.........................................SSS.........S........................................................................................................................................................................................................................................................................................................................................................................................................................................................**
On entry to DGEEV , parameter number  5 had an illegal value
** On entry to DGEEV , parameter number  5 had an illegal value
............/Users/rgommers/Code/scipy/scipy/signal/filter_design.py:224:
BadCoefficients: Badly conditioned filter coefficients (numerator): the
results may be meaningless
  "results may be meaningless", BadCoefficients)
..............................................................................................................................................................................................................................................................................................SSSSSSSSSSS...............K.......................................................................................................................................K...............................................................K.........................................................................................................................................................KK.......................................................................................................................................................................................................................................................................................................................................................................................................K.K...................................................................................................................................................................................................................................................................................................................................................................................K........K.......F.SSSSS................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S...................................................................................................................................................................................../Users/rgommers/Code/scipy/scipy/stats/morestats.py:702:
UserWarning: Ties preclude use of exact statistic.
  warnings.warn("Ties preclude use of exact statistic.")
.............................................................................................................................................................................................../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `samplestd` is deprecated!

scipy.stats.samplestd is deprecated; please update your code to use
numpy.std.

Please note that `numpy.std` axis argument defaults to None, not 0.

  warnings.warn(depdoc, DeprecationWarning)
/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `samplevar` is deprecated!

scipy.stats.samplevar is deprecated; please update your code to use
numpy.var.

Please note that `numpy.var` axis argument defaults to None, not 0.

  warnings.warn(depdoc, DeprecationWarning)
...../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `stderr` is deprecated!

scipy.stats.stderr is deprecated; please update your code to use
scipy.stats.sem.

  warnings.warn(depdoc, DeprecationWarning)
../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `z` is deprecated!

scipy.stats.z is deprecated; please update your code to use
scipy.stats.zscore_compare.

  warnings.warn(depdoc, DeprecationWarning)
../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
DeprecationWarning: `zs` is deprecated!

scipy.stats.zs is deprecated; please update your code to use
scipy.stats.zscore.

  warnings.warn(depdoc, DeprecationWarning)
..........................................Warning: friedmanchisquare test
using Chisquared aproximation
................warning: specified build_dir '_bad_path_' does not exist or
is not writable. Trying default locations
...warning: specified build_dir '..' does not exist or is not writable.
Trying default locations
..warning: specified build_dir '_bad_path_' does not exist or is not
writable. Trying default locations
...warning: specified build_dir '..' does not exist or is not writable.
Trying default locations
............................building extensions here:
/Users/rgommers/.python26_compiled/m48
................................................................................................
======================================================================
ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x3657970>,
(array([[  1.734e-255,   8.189e-217,   4.025e-178,   1.903e-139,
9.344e-101,
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
line 183, in runTest
    self.test(*self.arg)
  File "/Users/rgommers/Code/scipy/scipy/linalg/tests/test_decomp.py", line
1074, in check_lapack_misaligned
    func(*a,**kwargs)
  File "/Users/rgommers/Code/scipy/scipy/linalg/basic.py", line 47, in solve
    a1, b1 = map(asarray_chkfinite,(a,b))
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/function_base.py",
line 586, in asarray_chkfinite
    raise ValueError, "array must not contain infs or NaNs"
ValueError: array must not contain infs or NaNs

======================================================================
FAIL: test_lambertw.test_values
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
line 183, in runTest
    self.test(*self.arg)
  File "/Users/rgommers/Code/scipy/scipy/special/tests/test_lambertw.py",
line 80, in test_values
    FuncData(w, data, (0,1), 2, rtol=1e-10, atol=1e-13).check()
  File "/Users/rgommers/Code/scipy/scipy/special/tests/testutils.py", line
187, in check
    assert False, "\n".join(msg)
AssertionError:
Max |adiff|: 2.5797
Max |rdiff|: 3.81511
Bad results for the following points (in output 0):
(-0.44800000000000001+0.40000000000000002j)                              0j
=> (-1.2370928928166736-1.6588828572971359j) !=
(-0.11855133765652383+0.66570534313583418j)  (rdiff
3.8151122286225245)

----------------------------------------------------------------------
Ran 4437 tests in 68.377s

FAILED (KNOWNFAIL=11, SKIP=38, errors=1, failures=1)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100515/570d19b3/attachment.html>

From d.l.goldsmith at gmail.com  Sat May 15 01:03:41 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 14 May 2010 22:03:41 -0700
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
	<AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
	<AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>
Message-ID: <AANLkTikUEVgli5Bww-Dk10s8yYDaEMrs-_hEe7ERwqQ7@mail.gmail.com>

On Fri, May 14, 2010 at 8:29 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Fri, May 14, 2010 at 11:58 PM, <josef.pktd at gmail.com> wrote:
>
>> On Fri, May 14, 2010 at 11:26 AM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> >> Bug, undesired feature or feature request ?
>> >> I have no idea whether or how the doceditor can blacklist a function
>> >> (or class instance) so it cannot be edited or so it redirects to the
>> >> correct location.
>> >
>> > Don't know either, but it would be very useful to be able to 'lock'
>> pages.
>> > Since I don't think that's possible right now, maybe a capitalized note
>> on
>> > each page is in order.
>>
>> Is there a way to add a note?
>>
>
> I meant in the comment field.
>
>
>> I also thought, setting all of the distribution instances to
>> "unimportant" would be useful as a short run measure, but there are
>> too many of them for me to do page-by-page by hand
>>
>> One more alternative, "unimportant" is the lowest category for page
>> editing, maybe it is possible to add a category "DO NOT EDIT"  if we
>> cannot look the page down.
>>
>> Either one of the above would help. I guess Pauli has to decide what is
> easiest.
>
> Ralf
>

I'm not entirely clear on the template problem to which you refer, but
perhaps looking at what I did for Polynomial.deriv (actually, all of
Polynomial's and Chebyshev's methods) might help?  In particular, both of
these classes are generated from a template, and so things in the docstring
that need to be substituted with the "value" of the template (i.e., either
Polynomial or Chebyshev) are named w/ "$name" (and references to similar
functions that use only a portion of the name use a ${nick}<rest of function
name> syntax); I don't know if this a universal feature of the Python
templating system, however - Charles H.?

Then, I included the following note in each method's discussion section:
"This docstring is written for and needs to be placed in this module's class
template, located in numpy/polynomial/polytemplate.py; its use therein
obviates the need of placement in any other Polynomial-derived class."  Is
(something like) this what you're after?  (Yes, I know it would be nice if
we didn't have to do this manually, but w/ copy-and-paste, it's not that big
a deal).

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100514/380e4eab/attachment.html>

From d.l.goldsmith at gmail.com  Sat May 15 02:09:35 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 14 May 2010 23:09:35 -0700
Subject: [SciPy-Dev] [SciPy-dev] namespace recommendation in scipy
	tutorial and docs for np.emath
In-Reply-To: <1cd32cbb1001030740q13a8c27cu77bd88b71c29f3ce@mail.gmail.com>
References: <1cd32cbb1001030740q13a8c27cu77bd88b71c29f3ce@mail.gmail.com>
Message-ID: <AANLkTilWkq1vrIcj4C1NTPKRwNaSvXoY9Frsb64s15EK@mail.gmail.com>

On Sun, Jan 3, 2010 at 8:40 AM, <josef.pktd at gmail.com> wrote:

> I'm going through some scipy tickets and I found
> http://projects.scipy.org/scipy/ticket/882
>
> I don't know much about the old usage of mixing (mixed up) namespaces.
> But I think it would be good if someone could check the namespace
> convention/recommendation in the basic scipy tutorial
>
> http://docs.scipy.org/doc/scipy/reference/tutorial/basic.html
>
> When I tried to figure out the difference between scipy.* and numpy.*,
> I also found that the functions in numpy.emath (numpy.scipy) have good
> docstrings, but they are not included in the docs (at least I don't
> find them), because
>
> http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.emath.rst/#numpy-docs-reference-routines-emath-rst
> is still a stub page without function links.
> http://docs.scipy.org/doc/numpy/reference/routines.emath.html
>
> Josef
>

Hi, Josef; I found this going through all my old unread emails.  I don't
understand how/why
http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.emath.rst/#numpy-docs-reference-routines-emath-rstbeing
"still as stub w/out function links" is the cause of the good
docstrings in numpy.emath (numpy.scipy) not being included in "the docs"
(and to which "docs" are you referring exactly).  Please elaborate.  Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100514/43ea260e/attachment.html>

From ralf.gommers at googlemail.com  Sat May 15 03:38:45 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 15 May 2010 15:38:45 +0800
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTikUEVgli5Bww-Dk10s8yYDaEMrs-_hEe7ERwqQ7@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
	<AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
	<AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>
	<AANLkTikUEVgli5Bww-Dk10s8yYDaEMrs-_hEe7ERwqQ7@mail.gmail.com>
Message-ID: <AANLkTinZilfjkaWDl1Z_UbfuKXLY0d-On3M1uW4Gh7dS@mail.gmail.com>

On Sat, May 15, 2010 at 1:03 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

>
> I'm not entirely clear on the template problem to which you refer, but
> perhaps looking at what I did for Polynomial.deriv (actually, all of
> Polynomial's and Chebyshev's methods) might help?  In particular, both of
> these classes are generated from a template, and so things in the docstring
> that need to be substituted with the "value" of the template (i.e., either
> Polynomial or Chebyshev) are named w/ "$name" (and references to similar
> functions that use only a portion of the name use a ${nick}<rest of function
> name> syntax); I don't know if this a universal feature of the Python
> templating system, however - Charles H.?
>
> Hmm, I hadn't seen that before, it's a different method from used in
scipy.stats/ndimage.

Sorry to have to say this, but those changes are not very useful. Those
pages should also be locked and not edited. The generated patches will be
nonsense, and copying over cosmetic changes like in Polynomial.deriv
manually is a lot of work. If you really want to make minor changes to those
templates, I suggest you provide a proper patch or github branch and ping
Charles to review/apply them.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100515/e7713a64/attachment.html>

From d.l.goldsmith at gmail.com  Sat May 15 04:38:55 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sat, 15 May 2010 01:38:55 -0700
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTinZilfjkaWDl1Z_UbfuKXLY0d-On3M1uW4Gh7dS@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
	<AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
	<AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>
	<AANLkTikUEVgli5Bww-Dk10s8yYDaEMrs-_hEe7ERwqQ7@mail.gmail.com>
	<AANLkTinZilfjkaWDl1Z_UbfuKXLY0d-On3M1uW4Gh7dS@mail.gmail.com>
Message-ID: <AANLkTindJJJvlVN00aVCKa8jySFIYLWNZn40buPLpE5s@mail.gmail.com>

On Sat, May 15, 2010 at 12:38 AM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
> On Sat, May 15, 2010 at 1:03 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>>
>> I'm not entirely clear on the template problem to which you refer, but
>> perhaps looking at what I did for Polynomial.deriv (actually, all of
>> Polynomial's and Chebyshev's methods) might help?  In particular, both of
>> these classes are generated from a template, and so things in the docstring
>> that need to be substituted with the "value" of the template (i.e., either
>> Polynomial or Chebyshev) are named w/ "$name" (and references to similar
>> functions that use only a portion of the name use a ${nick}<rest of function
>> name> syntax); I don't know if this a universal feature of the Python
>> templating system, however - Charles H.?
>>
>> Hmm, I hadn't seen that before, it's a different method from used in
> scipy.stats/ndimage.
>
> Sorry to have to say this, but those changes are not very useful.
>

Please explain/elaborate.


> Those pages should also be locked and not edited.
>

Well, yes, if the Wiki supported editing the template's docstring, but it
doesn't, so...


> The generated patches will be nonsense, and copying over cosmetic changes
> like in Polynomial.deriv manually is a lot of work.
>

Well, that would appear to be a price we pay for using templating.


> If you really want to make minor changes to those templates,
>

IIRC, not all of my changes were minor.

I suggest you provide a proper patch
>

I.e., a source code patch?


> or github branch and ping Charles to review/apply them.
>

I believe in general, to the extent possible, we want independent eyes to be
reviewing docstrings (i.e., neither the code nor the docstring author), yes?

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100515/a1018918/attachment.html>

From ralf.gommers at googlemail.com  Sat May 15 06:13:44 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sat, 15 May 2010 18:13:44 +0800
Subject: [SciPy-Dev] distribution docstring generation
In-Reply-To: <AANLkTindJJJvlVN00aVCKa8jySFIYLWNZn40buPLpE5s@mail.gmail.com>
References: <AANLkTimMia6EAu3DN8K9OVItRjjR-HhWDDDTh_ofrdXz@mail.gmail.com>
	<AANLkTinbipocla2a-UVyvpoeQnrT1qbgp9VU9umpqpdp@mail.gmail.com>
	<AANLkTimvSMQreadj4CTk7ZPiP9NXedZQN3HnYDiwwNhH@mail.gmail.com>
	<AANLkTikCzxcmlyaE-yXspAxYSxKnUIfQb9qGaxs2kuVz@mail.gmail.com>
	<AANLkTil_n1nid6SZQuWrze5UURJnq3_Ew3Qh6iZy4Xhl@mail.gmail.com>
	<AANLkTikoFiSP5r_rsqTlfPrzAX6wIcUlyggbxMQ8I6Mr@mail.gmail.com>
	<AANLkTikUEVgli5Bww-Dk10s8yYDaEMrs-_hEe7ERwqQ7@mail.gmail.com>
	<AANLkTinZilfjkaWDl1Z_UbfuKXLY0d-On3M1uW4Gh7dS@mail.gmail.com>
	<AANLkTindJJJvlVN00aVCKa8jySFIYLWNZn40buPLpE5s@mail.gmail.com>
Message-ID: <AANLkTim1wJjE5-FKNYxCYrO4b5Faq6E9sGM4UI2AJxWx@mail.gmail.com>

On Sat, May 15, 2010 at 4:38 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> On Sat, May 15, 2010 at 12:38 AM, Ralf Gommers <
> ralf.gommers at googlemail.com> wrote:
>
>>
>> On Sat, May 15, 2010 at 1:03 PM, David Goldsmith <d.l.goldsmith at gmail.com
>> > wrote:
>>
>>>
>>> I'm not entirely clear on the template problem to which you refer, but
>>> perhaps looking at what I did for Polynomial.deriv (actually, all of
>>> Polynomial's and Chebyshev's methods) might help?  In particular, both of
>>> these classes are generated from a template, and so things in the docstring
>>> that need to be substituted with the "value" of the template (i.e., either
>>> Polynomial or Chebyshev) are named w/ "$name" (and references to similar
>>> functions that use only a portion of the name use a ${nick}<rest of function
>>> name> syntax); I don't know if this a universal feature of the Python
>>> templating system, however - Charles H.?
>>>
>>> Hmm, I hadn't seen that before, it's a different method from used in
>> scipy.stats/ndimage.
>>
>> Sorry to have to say this, but those changes are not very useful.
>>
>
> Please explain/elaborate.
>

I mean it would take someone else a lot of time to review this and get it
into svn, and it's not likely someone will actually take that time IMHO.

>
>
>> Those pages should also be locked and not edited.
>>
>
> Well, yes, if the Wiki supported editing the template's docstring, but it
> doesn't, so...
>
>
>> The generated patches will be nonsense, and copying over cosmetic changes
>> like in Polynomial.deriv manually is a lot of work.
>>
>
> Well, that would appear to be a price we pay for using templating.
>

No, same answer as above. Just don't use the wiki for these docstrings until
it supports the template system (which it perhaps never will).

>
>
>> If you really want to make minor changes to those templates,
>>
>
> IIRC, not all of my changes were minor.
>
> I suggest you provide a proper patch
>>
>
> I.e., a source code patch?
>

Yes.

>
>
>> or github branch and ping Charles to review/apply them.
>>
>
> I believe in general, to the extent possible, we want independent eyes to
> be reviewing docstrings (i.e., neither the code nor the docstring author),
> yes?
>
> Ideally, yes. But that doesn't mean reasonable changes can't be applied
before an independent review.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100515/f0e6a0f9/attachment.html>

From josef.pktd at gmail.com  Sat May 15 07:12:25 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 15 May 2010 07:12:25 -0400
Subject: [SciPy-Dev] test output - io and stats
In-Reply-To: <AANLkTinz_XtOOecPsOrycZGOgOqCaDtupfuTFPYiPTPp@mail.gmail.com>
References: <AANLkTinz_XtOOecPsOrycZGOgOqCaDtupfuTFPYiPTPp@mail.gmail.com>
Message-ID: <AANLkTik7Czgzgui3rTOgW5vClV0OWPip6W6BsW2iOYwU@mail.gmail.com>

On Sat, May 15, 2010 at 12:04 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> Hi,
>
> In two weeks we'll create the 0.8 branch, and it would be good to have the
> test output cleaned up before then. It is very noisy, the main offenders are
> the io and stats modules. Output pasted below, most of it is deprecations
> and future warnings.
>
> Matthew and Josef, will you have time for some spring cleaning in the next
> few weeks?

I won't have much time, however in your output, I only see
depreciation warnings for scipy stats and, I think, (almost) all of
them are intentional. So the only way to reduce this noise would be to
turn off depreciation warnings in the test run.

I think, if you run the "full" tests there are more warnings about
about numerical problems with integrate or similar.

Josef

>
> Thanks,
> Ralf
>
>
>
> Running unit tests for scipy
> NumPy version 1.4.1
> NumPy is installed in
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy
> SciPy version 0.8.0.dev
> SciPy is installed in /Users/rgommers/Code/scipy/scipy
> Python version 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32) [GCC 4.0.1 (Apple
> Inc. build 5493)]
> nose version 0.11.1
> .............................................................................................................................................................................................................................................................................../Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:512:
> UserWarning:
> The coefficients of the spline returned have been computed as the
> minimal norm least-squares solution of a (numerically) rank deficient
> system (deficiency=7). If deficiency is large, the results may be
> inaccurate. Deficiency may strongly depend on the value of eps.
> ? warnings.warn(message)
> ...../Users/rgommers/Code/scipy/scipy/interpolate/fitpack2.py:453:
> UserWarning:
> The required storage space exceeds the available storage space: nxest
> or nyest too small, or s too small.
> The weighted least-squares spline corresponds to the current set of
> knots.
> ? warnings.warn(message)
> ...........................................K..K................................................................................................................/Users/rgommers/Code/scipy/scipy/io/matlab/mio.py:190:
> FutureWarning: Using oned_as default value ('column') This will change to
> 'row' in future versions
> ? oned_as=oned_as)
> ........................./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:435:
> FutureWarning: Using oned_as default value ('column') This will change to
> 'row' in future versions
> ? mfw = MatFile5Writer(StringIO())
> ....../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:450:
> FutureWarning: Using oned_as default value ('column') This will change to
> 'row' in future versions
> ? wtr = MatFile5Writer(sio)
> ../Users/rgommers/Code/scipy/scipy/io/matlab/mio.py:99: FutureWarning: Using
> struct_as_record default value (False) This will change to True in future
> versions
> ? return MatFile5Reader(byte_stream, **kwargs)
> .............................../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:633:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:637:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream, squeeze_me=True)
> ../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:641:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream, byte_order=boc.native_code)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:645:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream, byte_order=boc.swapped_code)
> ../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:652:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:654:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream, chars_as_strings=False)
> ../Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:664:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(file(estring_fname))
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:674:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:679:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(stream)
> ../Users/rgommers/Code/scipy/scipy/io/matlab/mio4.py:338:
> DeprecationWarning: Matlab 4 files only support <=2 dimensions; future
> versions of scipy will raise an error when trying to write >2D arrays to
> matlab 4 format files
> ? DeprecationWarning,
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:699:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(file(func_eg))
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:703:
> FutureWarning: Using oned_as default value ('column') This will change to
> 'row' in future versions
> ? wtr = MatFile5Writer(stream)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:709:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(file(double_eg), mat_dtype=False)
> ./Users/rgommers/Code/scipy/scipy/io/matlab/tests/test_mio.py:712:
> FutureWarning: Using struct_as_record default value (False) This will change
> to True in future versions
> ? rdr = MatFile5Reader(file(double_eg), mat_dtype=True)
> .................................................................................................................................Warning:
> 1000000 bytes requested, 20 bytes read.
> ./Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `write_array` is deprecated!
>
> This function is replaced by numpy.savetxt which allows the same
> functionality
> through a different syntax.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `read_array` is deprecated!
>
> The functionality of read_array is in numpy.loadtxt which allows the same
> functionality using different syntax.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ...........................................Exception AttributeError:
> "'netcdf_file' object has no attribute 'mode'" in <bound method
> netcdf_file.close of <scipy.io.netcdf.netcdf_file object at 0x56c9750>>
> ignored
> ............/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `npfile` is deprecated!
>
> You can achieve the same effect as using npfile using numpy.save and
> numpy.load.
>
> You can use memory-mapped arrays and data-types to map out a
> file format for direct manipulation in NumPy.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ........./Users/rgommers/Code/scipy/scipy/io/wavfile.py:20: WavFileWarning:
> Unfamiliar format bytes
> ? warnings.warn("Unfamiliar format bytes", WavFileWarning)
> /Users/rgommers/Code/scipy/scipy/io/wavfile.py:92: WavFileWarning: chunk not
> understood
> ? warnings.warn("chunk not understood", WavFileWarning)
> ...[14 36 39 56 57] [14 36 39 56 57]
> .[[ 26? 10]
> ?[ 42 104]
> ?[? 1 102]
> ?[ 92?? 5]
> ?[ 72? 95]] [[ 26? 10]
> ?[ 42 104]
> ?[? 1 102]
> ?[ 92?? 5]
> ?[ 72? 95]]
> .[[? 9? 82?? 2? 84? 43]
> ?[122? 86? 18? 41? 79]
> ?[ 95? 99? 69 100? 40]
> ?[126?? 9 124? 38? 65]
> ?[ 59? 80? 90 122? 85]] [[? 9? 82?? 2? 84? 43]
> ?[122? 86? 18? 41? 79]
> ?[ 95? 99? 69 100? 40]
> ?[126?? 9 124? 38? 65]
> ?[ 59? 80? 90 122? 85]]
> .[ 16? 17? 89? 63 123] [ 16? 17? 89? 63 123]
> .[[ 63 113]
> ?[ 41? 36]
> ?[ 44? 31]
> ?[ 76?? 2]
> ?[127? 47]] [[ 63 113]
> ?[ 41? 36]
> ?[ 44? 31]
> ?[ 76?? 2]
> ?[127? 47]]
> .[[ 36?? 9? 59 117 116]
> ?[? 4? 75? 11 106? 63]
> ?[ 79? 82 126? 55 117]
> ?[ 79? 29?? 1? 24? 35]
> ?[ 29? 14 107? 79? 86]] [[ 36?? 9? 59 117 116]
> ?[? 4? 75? 11 106? 63]
> ?[ 79? 82 126? 55 117]
> ?[ 79? 29?? 1? 24? 35]
> ?[ 29? 14 107? 79? 86]]
> .[ 54? 42? 52 115? 88] [ 54? 42? 52 115? 88]
> .[[ 27? 30]
> ?[ 47? 77]
> ?[ 91? 26]
> ?[ 74 123]
> ?[ 73? 86]] [[ 27? 30]
> ?[ 47? 77]
> ?[ 91? 26]
> ?[ 74 123]
> ?[ 73? 86]]
> .[[? 5? 99? 21? 83? 34]
> ?[124? 47? 65? 29 127]
> ?[121?? 2? 53? 33? 55]
> ?[? 6 124? 25? 98? 97]
> ?[ 59? 57? 16 110? 83]] [[? 5? 99? 21? 83? 34]
> ?[124? 47? 65? 29 127]
> ?[121?? 2? 53? 33? 55]
> ?[? 6 124? 25? 98? 97]
> ?[ 59? 57? 16 110? 83]]
> .[ 6 20 32 27 92] [ 6 20 32 27 92]
> .[[ 80 108]
> ?[ 55? 65]
> ?[ 28? 57]
> ?[ 14 112]
> ?[? 9? 29]] [[ 80 108]
> ?[ 55? 65]
> ?[ 28? 57]
> ?[ 14 112]
> ?[? 9? 29]]
> .[[ 41 126? 18? 66? 47]
> ?[ 68? 59? 90? 71? 82]
> ?[ 55? 88? 48? 64 112]
> ?[ 59? 19? 86? 52 117]
> ?[? 8? 21? 14? 59? 99]] [[ 41 126? 18? 66? 47]
> ?[ 68? 59? 90? 71? 82]
> ?[ 55? 88? 48? 64 112]
> ?[ 59? 19? 86? 52 117]
> ?[? 8? 21? 14? 59? 99]]
> .[104? 76? 54? 96? 62] [104? 76? 54? 96? 62]
> .[[ 40? 61]
> ?[112? 33]
> ?[ 20? 22]
> ?[ 33? 68]
> ?[ 54? 46]] [[ 40? 61]
> ?[112? 33]
> ?[ 20? 22]
> ?[ 33? 68]
> ?[ 54? 46]]
> .[[ 86? 36? 82? 46 106]
> ?[? 6 104? 86? 41? 53]
> ?[ 13 110 123? 70? 76]
> ?[101? 14? 98? 63 100]
> ?[ 57? 23?? 3? 13? 38]] [[ 86? 36? 82? 46 106]
> ?[? 6 104? 86? 41? 53]
> ?[ 13 110 123? 70? 76]
> ?[101? 14? 98? 63 100]
> ?[ 57? 23?? 3? 13? 38]]
> .[ 6 17 59 54 34] [ 6 17 59 54 34]
> .[[71 68]
> ?[42 73]
> ?[60 70]
> ?[24 11]
> ?[93? 1]] [[71 68]
> ?[42 73]
> ?[60 70]
> ?[24 11]
> ?[93? 1]]
> .[[ 58?? 3? 60? 27? 96]
> ?[ 87? 55? 79 117? 83]
> ?[121 121? 38? 96? 23]
> ?[? 4?? 3? 65? 74? 81]
> ?[? 2 121? 64? 71? 88]] [[ 58?? 3? 60? 27? 96]
> ?[ 87? 55? 79 117? 83]
> ?[121 121? 38? 96? 23]
> ?[? 4?? 3? 65? 74? 81]
> ?[? 2 121? 64? 71? 88]]
> .[111? 40? 36? 64? 39] [111? 40? 36? 64? 39]
> .[[ 30 121]
> ?[ 38 119]
> ?[ 12? 75]
> ?[109? 62]
> ?[ 28? 89]] [[ 30 121]
> ?[ 38 119]
> ?[ 12? 75]
> ?[109? 62]
> ?[ 28? 89]]
> .[[ 43? 96 101? 73? 99]
> ?[ 40 119? 91? 13? 69]
> ?[ 53 121? 62? 40? 32]
> ?[ 92 106? 37 112?? 9]
> ?[ 81? 35? 80? 11? 96]] [[ 43? 96 101? 73? 99]
> ?[ 40 119? 91? 13? 69]
> ?[ 53 121? 62? 40? 32]
> ?[ 92 106? 37 112?? 9]
> ?[ 81? 35? 80? 11? 96]]
> .[105? 71 115 123? 51] [105? 71 115 123? 51]
> .[[ 54? 84]
> ?[106 124]
> ?[117?? 8]
> ?[? 0? 64]
> ?[ 65 100]] [[ 54? 84]
> ?[106 124]
> ?[117?? 8]
> ?[? 0? 64]
> ?[ 65 100]]
> .[[ 28 117 109? 49? 39]
> ?[ 74? 52 106 126? 97]
> ?[ 60? 77? 74? 22? 20]
> ?[ 34 110? 34? 61? 93]
> ?[? 2? 62? 22? 38? 57]] [[ 28 117 109? 49? 39]
> ?[ 74? 52 106 126? 97]
> ?[ 60? 77? 74? 22? 20]
> ?[ 34 110? 34? 61? 93]
> ?[? 2? 62? 22? 38? 57]]
> .[ 20 112? 14? 33? 78] [ 20 112? 14? 33? 78]
> .[[112? 51]
> ?[ 85? 88]
> ?[ 61? 38]
> ?[123?? 6]
> ?[113? 84]] [[112? 51]
> ?[ 85? 88]
> ?[ 61? 38]
> ?[123?? 6]
> ?[113? 84]]
> .[[? 4? 49?? 4? 89 121]
> ?[ 88? 77? 91? 37? 26]
> ?[ 79 124 107? 43? 90]
> ?[ 10? 23? 74? 78? 21]
> ?[122? 67? 96 120 127]] [[? 4? 49?? 4? 89 121]
> ?[ 88? 77? 91? 37? 26]
> ?[ 79 124 107? 43? 90]
> ?[ 10? 23? 74? 78? 21]
> ?[122? 67? 96 120 127]]
> .[21? 8 91 95 95] [21? 8 91 95 95]
> .[[ 30 100]
> ?[? 1? 20]
> ?[ 52 112]
> ?[ 56? 72]
> ?[ 39? 99]] [[ 30 100]
> ?[? 1? 20]
> ?[ 52 112]
> ?[ 56? 72]
> ?[ 39? 99]]
> .[[ 83? 36? 41 101 109]
> ?[ 76 119? 62? 33? 41]
> ?[113? 42 118 104 125]
> ?[ 19? 59? 87 101? 99]
> ?[ 77? 50? 65 117 104]] [[ 83? 36? 41 101 109]
> ?[ 76 119? 62? 33? 41]
> ?[113? 42 118 104 125]
> ?[ 19? 59? 87 101? 99]
> ?[ 77? 50? 65 117 104]]
> .[ 93 126 106? 60? 99] [ 93 126 106? 60? 99]
> .[[104? 10]
> ?[100 112]
> ?[125? 30]
> ?[ 59? 94]
> ?[ 44? 28]] [[104? 10]
> ?[100 112]
> ?[125? 30]
> ?[ 59? 94]
> ?[ 44? 28]]
> .[[ 10 106? 83 102? 41]
> ?[ 91? 93? 45? 87? 61]
> ?[ 37 123? 68? 52? 83]
> ?[? 5?? 5? 49 121? 87]
> ?[ 89? 59? 69 111 107]] [[ 10 106? 83 102? 41]
> ?[ 91? 93? 45? 87? 61]
> ?[ 37 123? 68? 52? 83]
> ?[? 5?? 5? 49 121? 87]
> ?[ 89? 59? 69 111 107]]
> .[94 71 80 50 71] [94 71 80 50 71]
> .[[106? 63]
> ?[ 63? 61]
> ?[111? 57]
> ?[122? 86]
> ?[ 54? 85]] [[106? 63]
> ?[ 63? 61]
> ?[111? 57]
> ?[122? 86]
> ?[ 54? 85]]
> .[[ 41 104 123? 11 104]
> ?[ 18?? 1? 97? 55? 20]
> ?[ 43?? 6? 18? 48? 72]
> ?[ 60? 45? 14? 17? 68]
> ?[ 97? 98? 46? 34? 49]] [[ 41 104 123? 11 104]
> ?[ 18?? 1? 97? 55? 20]
> ?[ 43?? 6? 18? 48? 72]
> ?[ 60? 45? 14? 17? 68]
> ?[ 97? 98? 46? 34? 49]]
> .[92 75 36 25? 1] [92 75 36 25? 1]
> .[[ 24?? 8]
> ?[ 95 111]
> ?[105? 95]
> ?[ 60 123]
> ?[ 46? 49]] [[ 24?? 8]
> ?[ 95 111]
> ?[105? 95]
> ?[ 60 123]
> ?[ 46? 49]]
> .[[116?? 6?? 2? 41? 43]
> ?[ 64? 43? 20? 36? 82]
> ?[ 43?? 8? 27? 87? 39]
> ?[ 14 115 121? 34? 49]
> ?[? 3? 49? 44? 72? 67]] [[116?? 6?? 2? 41? 43]
> ?[ 64? 43? 20? 36? 82]
> ?[ 43?? 8? 27? 87? 39]
> ?[ 14 115 121? 34? 49]
> ?[? 3? 49? 44? 72? 67]]
> .[ 53 116? 82? 51? 18] [ 53 116? 82? 51? 18]
> .[[ 65? 78]
> ?[123? 17]
> ?[ 42? 25]
> ?[ 20? 95]
> ?[ 26 121]] [[ 65? 78]
> ?[123? 17]
> ?[ 42? 25]
> ?[ 20? 95]
> ?[ 26 121]]
> .[[ 65? 58? 77? 95? 83]
> ?[ 72? 49? 55? 60? 54]
> ?[ 52?? 2? 29? 22?? 4]
> ?[119? 66? 91? 99 127]
> ?[105? 19 120? 41 106]] [[ 65? 58? 77? 95? 83]
> ?[ 72? 49? 55? 60? 54]
> ?[ 52?? 2? 29? 22?? 4]
> ?[119? 66? 91? 99 127]
> ?[105? 19 120? 41 106]]
> .[ 68 100?? 1? 21? 41] [ 68 100?? 1? 21? 41]
> .[[ 87? 86]
> ?[ 86 112]
> ?[ 92? 39]
> ?[ 33 101]
> ?[ 70 116]] [[ 87? 86]
> ?[ 86 112]
> ?[ 92? 39]
> ?[ 33 101]
> ?[ 70 116]]
> .[[? 3? 45 106? 58? 51]
> ?[ 52? 13? 54 124? 85]
> ?[ 36? 43? 45 122? 86]
> ?[ 74 118?? 7? 53? 83]
> ?[ 98? 53? 39? 78? 85]] [[? 3? 45 106? 58? 51]
> ?[ 52? 13? 54 124? 85]
> ?[ 36? 43? 45 122? 86]
> ?[ 74 118?? 7? 53? 83]
> ?[ 98? 53? 39? 78? 85]]
> .[? 4? 21? 40? 10 122] [? 4? 21? 40? 10 122]
> .[[104? 50]
> ?[ 74? 68]
> ?[ 89? 85]
> ?[ 46 100]
> ?[ 73?? 0]] [[104? 50]
> ?[ 74? 68]
> ?[ 89? 85]
> ?[ 46 100]
> ?[ 73?? 0]]
> .[[ 81? 41?? 8? 61? 38]
> ?[ 81? 85?? 9? 80? 29]
> ?[ 67? 51? 12? 53? 95]
> ?[107? 73? 56? 63? 35]
> ?[ 54? 44? 28? 73? 64]] [[ 81? 41?? 8? 61? 38]
> ?[ 81? 85?? 9? 80? 29]
> ?[ 67? 51? 12? 53? 95]
> ?[107? 73? 56? 63? 35]
> ?[ 54? 44? 28? 73? 64]]
> .[ 30? 89 121? 95? 30] [ 30? 89 121? 95? 30]
> .[[ 61? 88]
> ?[ 97? 97]
> ?[ 73? 36]
> ?[127? 70]
> ?[110? 65]] [[ 61? 88]
> ?[ 97? 97]
> ?[ 73? 36]
> ?[127? 70]
> ?[110? 65]]
> .[[ 71 103? 38? 26? 28]
> ?[ 87? 23?? 0? 43? 43]
> ?[106 115 110? 93?? 7]
> ?[ 73? 24? 79?? 1 118]
> ?[100 117? 70? 27? 21]] [[ 71 103? 38? 26? 28]
> ?[ 87? 23?? 0? 43? 43]
> ?[106 115 110? 93?? 7]
> ?[ 73? 24? 79?? 1 118]
> ?[100 117? 70? 27? 21]]
> .[ 28? 44 110? 14 113] [ 28? 44 110? 14 113]
> .[[ 72? 99]
> ?[120? 15]
> ?[ 79? 49]
> ?[ 49 126]
> ?[ 82? 26]] [[ 72? 99]
> ?[120? 15]
> ?[ 79? 49]
> ?[ 49 126]
> ?[ 82? 26]]
> .[[118 125? 53? 78 125]
> ?[? 9? 51? 77 100? 83]
> ?[109? 92 123 127?? 6]
> ?[ 20 118? 18? 35? 19]
> ?[ 13? 96 126? 84 117]] [[118 125? 53? 78 125]
> ?[? 9? 51? 77 100? 83]
> ?[109? 92 123 127?? 6]
> ?[ 20 118? 18? 35? 19]
> ?[ 13? 96 126? 84 117]]
> .[ 56? 95? 85 103? 23] [ 56? 95? 85 103? 23]
> .[[ 15? 42]
> ?[ 90? 17]
> ?[ 83?? 2]
> ?[ 59? 74]
> ?[125? 74]] [[ 15? 42]
> ?[ 90? 17]
> ?[ 83?? 2]
> ?[ 59? 74]
> ?[125? 74]]
> .[[? 3? 80? 60 112? 91]
> ?[? 6 101? 74? 31 117]
> ?[111? 80? 47? 67? 69]
> ?[? 2? 92? 61? 46? 88]
> ?[ 81 127? 44? 74? 15]] [[? 3? 80? 60 112? 91]
> ?[? 6 101? 74? 31 117]
> ?[111? 80? 47? 67? 69]
> ?[? 2? 92? 61? 46? 88]
> ?[ 81 127? 44? 74? 15]]
> .[40 81 89 29 77] [40 81 89 29 77]
> .[[ 45? 45]
> ?[? 1? 63]
> ?[109?? 7]
> ?[? 2 121]
> ?[ 84?? 3]] [[ 45? 45]
> ?[? 1? 63]
> ?[109?? 7]
> ?[? 2 121]
> ?[ 84?? 3]]
> .[[113 104 111? 23? 40]
> ?[ 91? 34? 78? 26? 36]
> ?[ 16? 34? 57?? 5 112]
> ?[ 42? 28? 13? 88 100]
> ?[100? 77? 89? 70 113]] [[113 104 111? 23? 40]
> ?[ 91? 34? 78? 26? 36]
> ?[ 16? 34? 57?? 5 112]
> ?[ 42? 28? 13? 88 100]
> ?[100? 77? 89? 70 113]]
> .[ 16 107? 80? 96? 80] [ 16 107? 80? 96? 80]
> .[[ 89? 70]
> ?[127? 78]
> ?[ 80? 44]
> ?[ 11 118]
> ?[ 55 105]] [[ 89? 70]
> ?[127? 78]
> ?[ 80? 44]
> ?[ 11 118]
> ?[ 55 105]]
> .[[ 19? 61? 95? 15? 21]
> ?[ 74? 42?? 4? 72? 86]
> ?[ 93 118? 97? 20? 81]
> ?[125?? 4? 35? 40? 56]
> ?[105? 72? 10? 84? 20]] [[ 19? 61? 95? 15? 21]
> ?[ 74? 42?? 4? 72? 86]
> ?[ 93 118? 97? 20? 81]
> ?[125?? 4? 35? 40? 56]
> ?[105? 72? 10? 84? 20]]
> .[ 60? 93? 20? 10 121] [ 60? 93? 20? 10 121]
> .[[118? 12]
> ?[ 16? 70]
> ?[ 17 123]
> ?[ 28? 91]
> ?[? 4 122]] [[118? 12]
> ?[ 16? 70]
> ?[ 17 123]
> ?[ 28? 91]
> ?[? 4 122]]
> .[[ 34? 75? 13? 58?? 1]
> ?[103? 94 122? 44? 24]
> ?[ 21? 82? 22 112?? 7]
> ?[120? 78? 51? 37? 96]
> ?[ 42? 16?? 7? 86? 96]] [[ 34? 75? 13? 58?? 1]
> ?[103? 94 122? 44? 24]
> ?[ 21? 82? 22 112?? 7]
> ?[120? 78? 51? 37? 96]
> ?[ 42? 16?? 7? 86? 96]]
> .[ 97 118? 25? 48? 27] [ 97 118? 25? 48? 27]
> .[[ 21?? 0]
> ?[111? 78]
> ?[? 3? 48]
> ?[ 67 118]
> ?[120? 71]] [[ 21?? 0]
> ?[111? 78]
> ?[? 3? 48]
> ?[ 67 118]
> ?[120? 71]]
> .[[ 75? 75 117? 16 110]
> ?[119 123?? 3? 62? 73]
> ?[ 68? 98? 56? 89? 43]
> ?[ 18? 47? 36? 75? 76]
> ?[? 9? 77? 86?? 2? 68]] [[ 75? 75 117? 16 110]
> ?[119 123?? 3? 62? 73]
> ?[ 68? 98? 56? 89? 43]
> ?[ 18? 47? 36? 75? 76]
> ?[? 9? 77? 86?? 2? 68]]
> .[40 25 77? 6 45] [40 25 77? 6 45]
> .[[104? 35]
> ?[ 37? 83]
> ?[108? 15]
> ?[113? 34]
> ?[ 60? 77]] [[104? 35]
> ?[ 37? 83]
> ?[108? 15]
> ?[113? 34]
> ?[ 60? 77]]
> .[[? 0? 65 108? 27 105]
> ?[ 63? 24? 31?? 9? 70]
> ?[ 64? 75? 93? 57 108]
> ?[? 9? 35? 37? 74? 62]
> ?[109 127? 69? 89? 46]] [[? 0? 65 108? 27 105]
> ?[ 63? 24? 31?? 9? 70]
> ?[ 64? 75? 93? 57 108]
> ?[? 9? 35? 37? 74? 62]
> ?[109 127? 69? 89? 46]]
> .[ 84 107? 81 125? 94] [ 84 107? 81 125? 94]
> .[[? 2 115]
> ?[120? 91]
> ?[ 91? 53]
> ?[ 63 109]
> ?[ 70? 60]] [[? 2 115]
> ?[120? 91]
> ?[ 91? 53]
> ?[ 63 109]
> ?[ 70? 60]]
> .[[101 106 105? 84? 47]
> ?[ 18? 87 124? 94? 45]
> ?[ 64? 40? 27? 33? 75]
> ?[ 87 109?? 8 119? 61]
> ?[ 70? 82? 34? 47? 46]] [[101 106 105? 84? 47]
> ?[ 18? 87 124? 94? 45]
> ?[ 64? 40? 27? 33? 75]
> ?[ 87 109?? 8 119? 61]
> ?[ 70? 82? 34? 47? 46]]
> .[100?? 0? 72 118? 26] [100?? 0? 72 118? 26]
> .[[27 42]
> ?[78 54]
> ?[ 1 88]
> ?[55 62]
> ?[49 83]] [[27 42]
> ?[78 54]
> ?[ 1 88]
> ?[55 62]
> ?[49 83]]
> .[[ 70? 55? 21 113? 61]
> ?[ 18 116 100? 65? 13]
> ?[126?? 6? 68? 39 109]
> ?[103 111? 63? 12 120]
> ?[ 13? 28? 84? 67? 82]] [[ 70? 55? 21 113? 61]
> ?[ 18 116 100? 65? 13]
> ?[126?? 6? 68? 39 109]
> ?[103 111? 63? 12 120]
> ?[ 13? 28? 84? 67? 82]]
> ...............................................................................................................................................SSSSSS......SSSSSS......SSSS..............................................................S.................................................../Users/rgommers/Code/scipy/scipy/linalg/decomp_qr.py:77:
> DeprecationWarning: qr econ argument will be removed after scipy 0.7. The
> economy transform will then be available through the mode='economic'
> argument.
> ? "the mode='economic' argument.", DeprecationWarning)
> ................................................................................................................................................................E....................................................................................................................................................
> ****************************************************************
> WARNING: clapack module is empty
> -----------
> See scipy/INSTALL.txt for troubleshooting.
> Notes:
> * If atlas library is not found by numpy/distutils/system_info.py,
> ? then scipy uses flapack instead of clapack.
> ****************************************************************
>
> ...Result may be inaccurate, approximate err = 7.68933681286e-09
> ...Result may be inaccurate, approximate err = 7.27595761418e-12
> .........................................SSS.........S........................................................................................................................................................................................................................................................................................................................................................................................................................................................**
> On entry to DGEEV , parameter number? 5 had an illegal value
> ** On entry to DGEEV , parameter number? 5 had an illegal value
> ............/Users/rgommers/Code/scipy/scipy/signal/filter_design.py:224:
> BadCoefficients: Badly conditioned filter coefficients (numerator): the
> results may be meaningless
> ? "results may be meaningless", BadCoefficients)
> ..............................................................................................................................................................................................................................................................................................SSSSSSSSSSS...............K.......................................................................................................................................K...............................................................K.........................................................................................................................................................KK.......................................................................................................................................................................................................................................................................................................................................................................................................K.K...................................................................................................................................................................................................................................................................................................................................................................................K........K.......F.SSSSS................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................S...................................................................................................................................................................................../Users/rgommers/Code/scipy/scipy/stats/morestats.py:702:
> UserWarning: Ties preclude use of exact statistic.
> ? warnings.warn("Ties preclude use of exact statistic.")
> .............................................................................................................................................................................................../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `samplestd` is deprecated!
>
> scipy.stats.samplestd is deprecated; please update your code to use
> numpy.std.
>
> Please note that `numpy.std` axis argument defaults to None, not 0.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `samplevar` is deprecated!
>
> scipy.stats.samplevar is deprecated; please update your code to use
> numpy.var.
>
> Please note that `numpy.var` axis argument defaults to None, not 0.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ...../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `stderr` is deprecated!
>
> scipy.stats.stderr is deprecated; please update your code to use
> scipy.stats.sem.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `z` is deprecated!
>
> scipy.stats.z is deprecated; please update your code to use
> scipy.stats.zscore_compare.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ../Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/utils.py:140:
> DeprecationWarning: `zs` is deprecated!
>
> scipy.stats.zs is deprecated; please update your code to use
> scipy.stats.zscore.
>
> ? warnings.warn(depdoc, DeprecationWarning)
> ..........................................Warning: friedmanchisquare test
> using Chisquared aproximation
> ................warning: specified build_dir '_bad_path_' does not exist or
> is not writable. Trying default locations
> ...warning: specified build_dir '..' does not exist or is not writable.
> Trying default locations
> ..warning: specified build_dir '_bad_path_' does not exist or is not
> writable. Trying default locations
> ...warning: specified build_dir '..' does not exist or is not writable.
> Trying default locations
> ............................building extensions here:
> /Users/rgommers/.python26_compiled/m48
> ................................................................................................
> ======================================================================
> ERROR: test_decomp.test_lapack_misaligned(<function solve at 0x3657970>,
> (array([[? 1.734e-255,?? 8.189e-217,?? 4.025e-178,?? 1.903e-139,
> 9.344e-101,
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ? File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
> line 183, in runTest
> ??? self.test(*self.arg)
> ? File "/Users/rgommers/Code/scipy/scipy/linalg/tests/test_decomp.py", line
> 1074, in check_lapack_misaligned
> ??? func(*a,**kwargs)
> ? File "/Users/rgommers/Code/scipy/scipy/linalg/basic.py", line 47, in solve
> ??? a1, b1 = map(asarray_chkfinite,(a,b))
> ? File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/lib/function_base.py",
> line 586, in asarray_chkfinite
> ??? raise ValueError, "array must not contain infs or NaNs"
> ValueError: array must not contain infs or NaNs
>
> ======================================================================
> FAIL: test_lambertw.test_values
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ? File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
> line 183, in runTest
> ??? self.test(*self.arg)
> ? File "/Users/rgommers/Code/scipy/scipy/special/tests/test_lambertw.py",
> line 80, in test_values
> ??? FuncData(w, data, (0,1), 2, rtol=1e-10, atol=1e-13).check()
> ? File "/Users/rgommers/Code/scipy/scipy/special/tests/testutils.py", line
> 187, in check
> ??? assert False, "\n".join(msg)
> AssertionError:
> Max |adiff|: 2.5797
> Max |rdiff|: 3.81511
> Bad results for the following points (in output 0):
> (-0.44800000000000001+0.40000000000000002j)????????????????????????????? 0j
> => (-1.2370928928166736-1.6588828572971359j) !=
> (-0.11855133765652383+0.66570534313583418j)? (rdiff
> 3.8151122286225245)
>
> ----------------------------------------------------------------------
> Ran 4437 tests in 68.377s
>
> FAILED (KNOWNFAIL=11, SKIP=38, errors=1, failures=1)
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From josef.pktd at gmail.com  Sat May 15 07:59:25 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sat, 15 May 2010 07:59:25 -0400
Subject: [SciPy-Dev] [SciPy-dev] namespace recommendation in scipy
	tutorial and docs for np.emath
In-Reply-To: <AANLkTilWkq1vrIcj4C1NTPKRwNaSvXoY9Frsb64s15EK@mail.gmail.com>
References: <1cd32cbb1001030740q13a8c27cu77bd88b71c29f3ce@mail.gmail.com>
	<AANLkTilWkq1vrIcj4C1NTPKRwNaSvXoY9Frsb64s15EK@mail.gmail.com>
Message-ID: <AANLkTikQF8ZpYS503kaMx6QBWmhfNhQqdbn0lhdwYbh-@mail.gmail.com>

On Sat, May 15, 2010 at 2:09 AM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Sun, Jan 3, 2010 at 8:40 AM, <josef.pktd at gmail.com> wrote:
>>
>> I'm going through some scipy tickets and I found
>> http://projects.scipy.org/scipy/ticket/882
>>
>> I don't know much about the old usage of mixing (mixed up) namespaces.
>> But I think it would be good if someone could check the namespace
>> convention/recommendation in the basic scipy tutorial
>>
>> http://docs.scipy.org/doc/scipy/reference/tutorial/basic.html
>>
>> When I tried to figure out the difference between scipy.* and numpy.*,
>> I also found that the functions in numpy.emath (numpy.scipy) have good
>> docstrings, but they are not included in the docs (at least I don't
>> find them), because
>>
>> http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.emath.rst/#numpy-docs-reference-routines-emath-rst
>> is still a stub page without function links.
>> http://docs.scipy.org/doc/numpy/reference/routines.emath.html
>>
>> Josef
>
> Hi, Josef; I found this going through all my old unread emails.? I don't
> understand how/why
> http://docs.scipy.org/numpy/docs/numpy-docs/reference/routines.emath.rst/#numpy-docs-reference-routines-emath-rst
> being "still as stub w/out function links" is the cause of the good
> docstrings in numpy.emath (numpy.scipy) not being included in "the docs"
> (and to which "docs" are you referring exactly).? Please elaborate.? Thanks!


this is empty
http://docs.scipy.org/doc/numpy/reference/routines.emath.html

e.g. this is not included in the docs
http://docs.scipy.org/numpy/docs/numpy.lib.scimath.arctanh/

only functions that are included with an autosummary or automodule
are included in the docs

since there is no autosummary statement in emath, none of the
numpy.lib.scimath.* docs are in the rendered documentation.

At least that was my impression, and it still looks this way.


Josef


>
> DG
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Sun May 16 01:49:54 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 16 May 2010 13:49:54 +0800
Subject: [SciPy-Dev] test output - io and stats
In-Reply-To: <AANLkTik7Czgzgui3rTOgW5vClV0OWPip6W6BsW2iOYwU@mail.gmail.com>
References: <AANLkTinz_XtOOecPsOrycZGOgOqCaDtupfuTFPYiPTPp@mail.gmail.com>
	<AANLkTik7Czgzgui3rTOgW5vClV0OWPip6W6BsW2iOYwU@mail.gmail.com>
Message-ID: <AANLkTilBHHZAT0B1KrHXzrF2IVGcP87WxiZaWereBf26@mail.gmail.com>

On Sat, May 15, 2010 at 7:12 PM, <josef.pktd at gmail.com> wrote:

> On Sat, May 15, 2010 at 12:04 AM, Ralf Gommers
> <ralf.gommers at googlemail.com> wrote:
> > Hi,
> >
> > In two weeks we'll create the 0.8 branch, and it would be good to have
> the
> > test output cleaned up before then. It is very noisy, the main offenders
> are
> > the io and stats modules. Output pasted below, most of it is deprecations
> > and future warnings.
> >
> > Matthew and Josef, will you have time for some spring cleaning in the
> next
> > few weeks?
>
> I won't have much time, however in your output, I only see
> depreciation warnings for scipy stats and, I think, (almost) all of
> them are intentional. So the only way to reduce this noise would be to
> turn off depreciation warnings in the test run.
>
> They can be filtered out. I think the test output for a release should be
silent, and this thread seems to confirm that:
http://thread.gmane.org/gmane.comp.python.numeric.general/21818/focus=21865



> I think, if you run the "full" tests there are more warnings about
> about numerical problems with integrate or similar.
>
>  Yes, there's other modules besides io and stats that are generating some
warnings, I will look at those.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100516/eb3a05ad/attachment.html>

From josef.pktd at gmail.com  Sun May 16 06:40:50 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Sun, 16 May 2010 06:40:50 -0400
Subject: [SciPy-Dev] test output - io and stats
In-Reply-To: <AANLkTilBHHZAT0B1KrHXzrF2IVGcP87WxiZaWereBf26@mail.gmail.com>
References: <AANLkTinz_XtOOecPsOrycZGOgOqCaDtupfuTFPYiPTPp@mail.gmail.com>
	<AANLkTik7Czgzgui3rTOgW5vClV0OWPip6W6BsW2iOYwU@mail.gmail.com>
	<AANLkTilBHHZAT0B1KrHXzrF2IVGcP87WxiZaWereBf26@mail.gmail.com>
Message-ID: <AANLkTikeimbipuCCB7SKuBR0FnT-Al3d4fVErhPthSkc@mail.gmail.com>

On Sun, May 16, 2010 at 1:49 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
>
>
> On Sat, May 15, 2010 at 7:12 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Sat, May 15, 2010 at 12:04 AM, Ralf Gommers
>> <ralf.gommers at googlemail.com> wrote:
>> > Hi,
>> >
>> > In two weeks we'll create the 0.8 branch, and it would be good to have
>> > the
>> > test output cleaned up before then. It is very noisy, the main offenders
>> > are
>> > the io and stats modules. Output pasted below, most of it is
>> > deprecations
>> > and future warnings.
>> >
>> > Matthew and Josef, will you have time for some spring cleaning in the
>> > next
>> > few weeks?
>>
>> I won't have much time, however in your output, I only see
>> depreciation warnings for scipy stats and, I think, (almost) all of
>> them are intentional. So the only way to reduce this noise would be to
>> turn off depreciation warnings in the test run.
>>
> They can be filtered out. I think the test output for a release should be
> silent, and this thread seems to confirm that:
> http://thread.gmane.org/gmane.comp.python.numeric.general/21818/focus=21865
>

I think these are mainly other type of warnings, for example we
wouldn't want to have Zerodivision error turned on, because dividing
by zero is supposed to be handled correctly.

But Depreciation warnings and numerical precision warnings,
non-convergence of an optimization or integral are quite useful for
the user to know.

If a user upgrades and sees DepreciationWarnings while running the
tests, it's a good reminder to check their own code for them.

But, I don't really care either way, a clean test run looks nice.

Josef

>
>>
>> I think, if you run the "full" tests there are more warnings about
>> about numerical problems with integrate or similar.
>>
> ?Yes, there's other modules besides io and stats that are generating some
> warnings, I will look at those.
>
> Cheers,
> Ralf
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From lasagnadavide at gmail.com  Sun May 16 12:13:54 2010
From: lasagnadavide at gmail.com (Davide Lasagna)
Date: Sun, 16 May 2010 18:13:54 +0200
Subject: [SciPy-Dev] Two dimensional Savitzky-Golay least-square filtering.
Message-ID: <AANLkTikeDgV9P2IY8anC72gj7bG8_uqhPVY5Y87ulB6a@mail.gmail.com>

Hi all,

I have added to the Scipy Cookbook a code that performs filtering of 2D data
using the Savitsky-Golay algorithm, which is based on local least-square
fitting with bivariate polynomials. It also allows to compute the first
derivatives of the 2D data, but i'm going to add higher order derivatives
soon. It works quite well and the code is reasonably fast for "large" data
sets. It would be nice to have this function available in scipy.interpolate,
and i'm asking to the list if it is worth improving the code and adding
documentation. To have an idea of what it can be achieved have a look at the
attachments in the cookbook.


Cheers

Davide Lasagna

PhD in Fluid Dynamics
Politecnico di Torino, Italy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100516/d6e4b3bc/attachment.html>

From gael.varoquaux at normalesup.org  Sun May 16 16:37:28 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 16 May 2010 22:37:28 +0200
Subject: [SciPy-Dev] [sympy] EuroScipy abstract submission deadline extended
Message-ID: <20100516203728.GJ19278@phare.normalesup.org>

Given that we have been able to turn on registration only very late, the
EuroScipy conference committee is extending the deadline for abstract
submission for the 2010 EuroScipy conference.

On Thursday May 20th, at midnight Samoa time, we will turn off the
abstract submission on the conference site. Up to then, you can modify
the already-submitted abstract, or submit new abstracts.

We are very much looking forward to your submissions to the conference.

Ga?l Varoquaux
Nicolas Chauvat

-- 
 
EuroScipy 2010 is the annual European conference for scientists using
Python. It will be held July 8-11 2010, in ENS, Paris, France.
 
Links: 
Conference website: http://www.euroscipy.org/conference/euroscipy2010
Call for papers: http://www.euroscipy.org/card/euroscipy2010_call_for_papers
Practical information: http://www.euroscipy.org/card/euroscipy2010_practical_information
 



From gael.varoquaux at normalesup.org  Sat May 15 18:40:12 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sun, 16 May 2010 00:40:12 +0200
Subject: [SciPy-Dev] EuroScipy abstract submission deadline extended
Message-ID: <20100515224012.GC19412@phare.normalesup.org>

Given that we have been able to turn on registration only very late, the
EuroScipy conference committee is extending the deadline for abstract
submission for the 2010 EuroScipy conference.

On Thursday May 20th, at midnight Samoa time, we will turn off the
abstract submission on the conference site. Up to then, you can modify
the already-submitted abstract, or submit new abstracts.

We are very much looking forward to your submissions to the conference.

Ga?l Varoquaux
Nicolas Chauvat

-- 
 
EuroScipy 2010 is the annual conference for scientists using Python. It
will be held July 8-11 2010, in ENS, Paris, France.
 
Links: 
Conference website: http://www.euroscipy.org/conference/euroscipy2010
Call for papers: http://www.euroscipy.org/card/euroscipy2010_call_for_papers
Practical information: http://www.euroscipy.org/card/euroscipy2010_practical_information
 



From josef.pktd at gmail.com  Mon May 17 12:25:40 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 17 May 2010 12:25:40 -0400
Subject: [SciPy-Dev] 2 functions scipy.stats.describe
Message-ID: <AANLkTilglq7skmkwnfUsra0m648nNPO4D-Cb7XqdP1U7@mail.gmail.com>

scipy.stats has two different functions with the same name scipy.stats.describe

Josef


From m.boumans at gmx.net  Mon May 17 23:45:23 2010
From: m.boumans at gmx.net (Marcus Boumans)
Date: Tue, 18 May 2010 05:45:23 +0200
Subject: [SciPy-Dev] Edit permission for Scipy doc
Message-ID: <4BF20D53.5080802@gmx.net>

Hello,

I would like to review and/or proofread the documentation.

Regs

Marcus


From gael.varoquaux at normalesup.org  Tue May 18 01:36:44 2010
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 18 May 2010 07:36:44 +0200
Subject: [SciPy-Dev] Edit permission for Scipy doc
In-Reply-To: <4BF20D53.5080802@gmx.net>
References: <4BF20D53.5080802@gmx.net>
Message-ID: <20100518053644.GC9440@phare.normalesup.org>

On Tue, May 18, 2010 at 05:45:23AM +0200, Marcus Boumans wrote:
> I would like to review and/or proofread the documentation.

I have given you edit rights.

Ga?l


From josef.pktd at gmail.com  Tue May 18 09:16:59 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 18 May 2010 09:16:59 -0400
Subject: [SciPy-Dev] 2 functions scipy.stats.describe
In-Reply-To: <AANLkTilglq7skmkwnfUsra0m648nNPO4D-Cb7XqdP1U7@mail.gmail.com>
References: <AANLkTilglq7skmkwnfUsra0m648nNPO4D-Cb7XqdP1U7@mail.gmail.com>
Message-ID: <AANLkTini0KCbhaSsuHOB3-_UV4_n4BPZhBY-9jCmMMny@mail.gmail.com>

On Mon, May 17, 2010 at 12:25 PM,  <josef.pktd at gmail.com> wrote:
> scipy.stats has two different functions with the same name scipy.stats.describe

BTW: Is the second describe supposed to be a Bayesian posterior
distribution, a sampling distribution or a mixture of the two?


def interval(self, alpha, *args, **kwds):
     """Confidence interval centered on the median

I don't think an equal-probability-tail confidence interval for an
asymmetric distribution is "centered" around anything.

Josef

> Josef
>


From jwilson556 at gmail.com  Wed May 19 00:00:56 2010
From: jwilson556 at gmail.com (James Wilson)
Date: Wed, 19 May 2010 04:00:56 +0000 (UTC)
Subject: [SciPy-Dev] scipy (0.7.2) build doesn't use UMFPACK
Message-ID: <loom.20100519T060003-403@post.gmane.org>

I compiled and installed UMFPACK and the scipy setup script appears to find it
correctly from my config output below.  When I try to test it, though:

>>> import scipy.sparse.linalg.dsolve.umfpack as um
>>> um.test(verbose=2)

All tests are skipped, and the output says "UMFPACK appears not to be compiled".
 Looking at nm dumps for the __umfpack.so module shows symbols from the
libumfpack.a, so it looks like it linked against it.  What can I do to get scipy
to see umfpack?

-James

from scipy.show_config():
amd_info:
    libraries = ['amd']
    library_dirs = ['/usr/local/lib']
    define_macros = [('SCIPY_AMD_H', None)]
    swig_opts = ['-I/usr/local/include']
    include_dirs = ['/usr/local/include']

umfpack_info:
    libraries = ['umfpack', 'amd']
    library_dirs = ['/usr/local/lib']
    define_macros = [('SCIPY_UMFPACK_H', None), ('SCIPY_AMD_H', None)]
    swig_opts = ['-I/usr/local/include', '-I/usr/local/include']
    include_dirs = ['/usr/local/include']





From d.l.goldsmith at gmail.com  Wed May 19 00:14:03 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 18 May 2010 21:14:03 -0700
Subject: [SciPy-Dev] Slightly OT: Is SciPy available on all OLPC-distributed
	laptops?
Message-ID: <AANLkTil_eKpF94SfTZBTLUpPV4KL2zxY_r7-wlYDVx5S@mail.gmail.com>

Hi!  I've spent the past 20 min. or so searching the OLPC site and (thanks
to Google) the IPython site for the answer to this simple yes-or-no
question; the best I was able to come up with is that IPython is part of the
standard OLPC software distribution, but I couldn't find an enumeration of
precisely what packages IPython comes with, nor a simple statement that it
includes (all of) SciPy.  Unless the answer is "no, SciPy is not guaranteed
to be on OLPC computers," can someone please furnish me w/ a URL that
confirms (explicitly or implicitly) that it is?  Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100518/6bfec087/attachment.html>

From d.l.goldsmith at gmail.com  Wed May 19 15:46:38 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Wed, 19 May 2010 12:46:38 -0700
Subject: [SciPy-Dev] Milestones link at the top of the SciPy Wiki
In-Reply-To: <AANLkTin735wEGiTqa72EV-MzMhYP0mDT9TS_3RaiXPzf@mail.gmail.com>
References: <AANLkTin735wEGiTqa72EV-MzMhYP0mDT9TS_3RaiXPzf@mail.gmail.com>
Message-ID: <AANLkTin_cKRxsv-LoHRZSuV78UuW8XzgsqSBjR2suWM-@mail.gmail.com>

This is still true...

DG

On Tue, May 11, 2010 at 8:11 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> Points to the NumPy Wiki Milestones page.
>
> DG
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100519/36585517/attachment.html>

From jsseabold at gmail.com  Wed May 19 22:55:02 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Wed, 19 May 2010 22:55:02 -0400
Subject: [SciPy-Dev] line endings in test failures?
Message-ID: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com>

I was working on some tests and I noticed that the AssertionError
raised by a test failure contains a line ending, '\n'.  I'm using
*Ubuntu/Linux, Python 2.6.5, and numpy version '2.0.0.dev8391'

Is this intended?  A nose issue?  Not a big deal I guess, but it makes
test output hard to read.

Here's an example of a failure in scipy version '0.8.0.dev6392'

======================================================================
FAIL: test_x_stride (test_fblas.TestCgemv)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/scipy/lib/blas/tests/test_fblas.py",
line 345, in test_x_stride
    assert_array_almost_equal(desired_y,y)
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 774, in assert_array_almost_equal
    header='Arrays are not almost equal')
  File "/usr/local/lib/python2.6/dist-packages/numpy/testing/utils.py",
line 618, in assert_array_compare
    raise AssertionError(msg)
AssertionError:
Arrays are not almost equal

(mismatch 33.3333333333%)
 x: array([ -1.93673837 +1.93673837j, -15.54586983+17.54586983j,
         2.03078222 +1.96921778j], dtype=complex64)
 y: array([ -1.93673837 +1.93673837j, -15.54586983+17.54587173j,
         2.03078222 +1.96921754j], dtype=complex64)
>>  raise AssertionError('\nArrays are not almost equal\n\n(mismatch 33.3333333333%)\n x: array([ -1.93673837 +1.93673837j, -15.54586983+17.54586983j,\n         2.03078222 +1.96921778j], dtype=complex64)\n y: array([ -1.93673837 +1.93673837j, -15.54586983+17.54587173j,\n         2.03078222 +1.96921754j], dtype=complex64)')

but just from the interpreter

>>> raise AssertionError('\n hello \n hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError:
 hello
 hello
>>>

Skipper


From d.l.goldsmith at gmail.com  Thu May 20 00:36:07 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Wed, 19 May 2010 21:36:07 -0700
Subject: [SciPy-Dev] Design of scipy.stats
Message-ID: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>

What's the relationship between distributions.<X> and
distributions.<X>_gen?  In particular, does the presence of a docstring in
the former obviate the need of one in the latter, and why?  Thanks!

DG

-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100519/c9d8a3e4/attachment.html>

From pav at iki.fi  Thu May 20 08:34:15 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 20 May 2010 12:34:15 +0000 (UTC)
Subject: [SciPy-Dev] line endings in test failures?
References: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com>
Message-ID: <ht3a87$1ka$1@dough.gmane.org>

Wed, 19 May 2010 22:55:02 -0400, Skipper Seabold wrote:
[clip]
> AssertionError:
> Arrays are not almost equal
> 
> (mismatch 33.3333333333%)
>  x: array([ -1.93673837 +1.93673837j, -15.54586983+17.54586983j,
>          2.03078222 +1.96921778j], dtype=complex64)
>  y: array([ -1.93673837 +1.93673837j, -15.54586983+17.54587173j,
>          2.03078222 +1.96921754j], dtype=complex64)
>>>  raise AssertionError('\nArrays are not almost equal\n\n(mismatch
>>>  33.3333333333%)\n x: array([ -1.93673837 +1.93673837j,
>>>  -15.54586983+17.54586983j,\n         2.03078222 +1.96921778j],
>>>  dtype=complex64)\n y: array([ -1.93673837 +1.93673837j,
>>>  -15.54586983+17.54587173j,\n         2.03078222 +1.96921754j],
>>>  dtype=complex64)')

That's Nose's --detailed-errors in action.

-- 
Pauli Virtanen



From jsseabold at gmail.com  Thu May 20 10:44:34 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Thu, 20 May 2010 10:44:34 -0400
Subject: [SciPy-Dev] line endings in test failures?
In-Reply-To: <ht3a87$1ka$1@dough.gmane.org>
References: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com> 
	<ht3a87$1ka$1@dough.gmane.org>
Message-ID: <AANLkTimPrYmcR5e7VMSiJnPW8CZpWP0vLElUdPD46qY1@mail.gmail.com>

On Thu, May 20, 2010 at 8:34 AM, Pauli Virtanen <pav at iki.fi> wrote:
> Wed, 19 May 2010 22:55:02 -0400, Skipper Seabold wrote:
> [clip]
>> AssertionError:
>> Arrays are not almost equal
>>
>> (mismatch 33.3333333333%)
>> ?x: array([ -1.93673837 +1.93673837j, -15.54586983+17.54586983j,
>> ? ? ? ? ?2.03078222 +1.96921778j], dtype=complex64)
>> ?y: array([ -1.93673837 +1.93673837j, -15.54586983+17.54587173j,
>> ? ? ? ? ?2.03078222 +1.96921754j], dtype=complex64)
>>>> ?raise AssertionError('\nArrays are not almost equal\n\n(mismatch
>>>> ?33.3333333333%)\n x: array([ -1.93673837 +1.93673837j,
>>>> ?-15.54586983+17.54586983j,\n ? ? ? ? 2.03078222 +1.96921778j],
>>>> ?dtype=complex64)\n y: array([ -1.93673837 +1.93673837j,
>>>> ?-15.54586983+17.54587173j,\n ? ? ? ? 2.03078222 +1.96921754j],
>>>> ?dtype=complex64)')
>
> That's Nose's --detailed-errors in action.
>

Ah, so it is.  Just out of curiosity, why did you turn this always on?
 I don't see what assert introspection adds in a case like this.  Is
it possible to make it optional but a default keyword to
NoseTester.test's extra_argv?

Skipper


From david.huard at gmail.com  Thu May 20 11:12:10 2010
From: david.huard at gmail.com (David Huard)
Date: Thu, 20 May 2010 11:12:10 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
Message-ID: <AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>

<X>_gen is a class and <X> an instance of that class.

David H.

On Thu, May 20, 2010 at 12:36 AM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> What's the relationship between distributions.<X> and
> distributions.<X>_gen?? In particular, does the presence of a docstring in
> the former obviate the need of one in the latter, and why?? Thanks!
>
> DG
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From pav at iki.fi  Thu May 20 12:52:49 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Thu, 20 May 2010 16:52:49 +0000 (UTC)
Subject: [SciPy-Dev] line endings in test failures?
References: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com>
	<ht3a87$1ka$1@dough.gmane.org>
	<AANLkTimPrYmcR5e7VMSiJnPW8CZpWP0vLElUdPD46qY1@mail.gmail.com>
Message-ID: <ht3pd1$23q$1@dough.gmane.org>

Thu, 20 May 2010 10:44:34 -0400, Skipper Seabold wrote:
[clip]
> Ah, so it is.  Just out of curiosity, why did you turn this always on?
>  I don't see what assert introspection adds in a case like this.  Is
> it possible to make it optional but a default keyword to
> NoseTester.test's extra_argv?

There were some tests that only did

	assert (something)

and it was useful to see what the something was on the buildbot, when 
they were failing. I don't think this can be turned on on a per-test 
basis.

Anyway, if it seems too disturbing, I guess it can be turned back off.

-- 
Pauli Virtanen



From jsseabold at gmail.com  Thu May 20 13:09:58 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Thu, 20 May 2010 13:09:58 -0400
Subject: [SciPy-Dev] line endings in test failures?
In-Reply-To: <ht3pd1$23q$1@dough.gmane.org>
References: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com> 
	<ht3a87$1ka$1@dough.gmane.org>
	<AANLkTimPrYmcR5e7VMSiJnPW8CZpWP0vLElUdPD46qY1@mail.gmail.com> 
	<ht3pd1$23q$1@dough.gmane.org>
Message-ID: <AANLkTil_9yezX7ZX0fskVLquIQ0Xvtj3KPzdzMAQG-cp@mail.gmail.com>

On Thu, May 20, 2010 at 12:52 PM, Pauli Virtanen <pav at iki.fi> wrote:
> Thu, 20 May 2010 10:44:34 -0400, Skipper Seabold wrote:
> [clip]
>> Ah, so it is. ?Just out of curiosity, why did you turn this always on?
>> ?I don't see what assert introspection adds in a case like this. ?Is
>> it possible to make it optional but a default keyword to
>> NoseTester.test's extra_argv?
>
> There were some tests that only did
>
> ? ? ? ?assert (something)
>
> and it was useful to see what the something was on the buildbot, when
> they were failing. I don't think this can be turned on on a per-test
> basis.
>
> Anyway, if it seems too disturbing, I guess it can be turned back off.
>

It really doesn't matter to me, if it's helpful to you, I just had to
sift through a lot of extra noise refactoring some tests.  We use a
monkey-patched version of NoseTester for statsmodels and if you apply
the following diff (numpy/tesing/nosetester.py), it would allow me to
get around the --detailed-errors.  I don't think it changes the new
default behavior for numpy, but makes it optional.


Index: nosetester.py
===================================================================
--- nosetester.py       (revision 8417)
+++ nosetester.py       (working copy)
@@ -230,9 +230,6 @@
             argv+=['--cover-package=%s' % self.package_name, '--with-coverage',
                    '--cover-tests', '--cover-inclusive', '--cover-erase']

-        # enable assert introspection
-        argv += ['--detailed-errors']
-
         # bypass these samples under distutils
         argv += ['--exclude','f2py_ext']
         argv += ['--exclude','f2py_f90_ext']
@@ -249,8 +246,8 @@
         plugins += [p() for p in nose.plugins.builtin.plugins]
         return argv, plugins

-    def test(self, label='fast', verbose=1, extra_argv=None, doctests=False,
-             coverage=False):
+    def test(self, label='fast', verbose=1, extra_argv=['--detailed-errors'],
+            doctests=False, coverage=False):
         """
         Run tests for module using nose.

Skipper


From d.l.goldsmith at gmail.com  Thu May 20 14:22:01 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 20 May 2010 11:22:01 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
Message-ID: <AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>

On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com> wrote:

> <X>_gen is a class and <X> an instance of that class.
>
> David H.
>

So which is a user expected to use?

DG


>
> On Thu, May 20, 2010 at 12:36 AM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > What's the relationship between distributions.<X> and
> > distributions.<X>_gen?  In particular, does the presence of a docstring
> in
> > the former obviate the need of one in the latter, and why?  Thanks!
> >
> > DG
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> uncertainty
> > set is non-empty, even if that set has measure zero.
> >
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/d666ae58/attachment.html>

From robert.kern at gmail.com  Thu May 20 14:24:02 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 20 May 2010 13:24:02 -0500
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com> 
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com> 
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
Message-ID: <AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>

On Thu, May 20, 2010 at 13:22, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com> wrote:
>>
>> <X>_gen is a class and <X> an instance of that class.
>>
>> David H.
>
> So which is a user expected to use?

The latter.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d.l.goldsmith at gmail.com  Thu May 20 14:53:23 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 20 May 2010 11:53:23 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
Message-ID: <AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>

So then that's actually the one that should be documented?  Or they both
should?  (Forgive me if I sound ignorant, but I'm not familiar w/ this API
model: I'm use to the library/package/module providing the class, as in
"class library," and then the user instantiating (or sub-classing) that as
s/he needs; I've never heard of an "instance library.")  Thanks again!

DG

On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, May 20, 2010 at 13:22, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
> > On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com>
> wrote:
> >>
> >> <X>_gen is a class and <X> an instance of that class.
> >>
> >> David H.
> >
> > So which is a user expected to use?
>
> The latter.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/b4bc0492/attachment.html>

From josef.pktd at gmail.com  Thu May 20 15:03:56 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 20 May 2010 15:03:56 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
Message-ID: <AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>

On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> So then that's actually the one that should be documented?? Or they both
> should?? (Forgive me if I sound ignorant, but I'm not familiar w/ this API
> model: I'm use to the library/package/module providing the class, as in
> "class library," and then the user instantiating (or sub-classing) that as
> s/he needs; I've never heard of an "instance library.")? Thanks again!

the docstrings are attached to or generated for the classes. The
instances get the docstrings from the class, and don't have separate
docstrings.

The instances are created for convenience (especially for users who
are not familiar with classes).

Josef


>
> DG
>
> On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Thu, May 20, 2010 at 13:22, David Goldsmith <d.l.goldsmith at gmail.com>
>> wrote:
>> > On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com>
>> > wrote:
>> >>
>> >> <X>_gen is a class and <X> an instance of that class.
>> >>
>> >> David H.
>> >
>> > So which is a user expected to use?
>>
>> The latter.
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless
>> enigma that is made terrible by our own mad attempt to interpret it as
>> though it had an underlying truth."
>> ?-- Umberto Eco
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From d.l.goldsmith at gmail.com  Thu May 20 16:26:00 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 20 May 2010 13:26:00 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
Message-ID: <AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>

On Thu, May 20, 2010 at 12:03 PM, <josef.pktd at gmail.com> wrote:

> On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > So then that's actually the one that should be documented?  Or they both
> > should?  (Forgive me if I sound ignorant, but I'm not familiar w/ this
> API
> > model: I'm use to the library/package/module providing the class, as in
> > "class library," and then the user instantiating (or sub-classing) that
> as
> > s/he needs; I've never heard of an "instance library.")  Thanks again!
>
> the docstrings are attached to or generated for the classes. The
> instances get the docstrings from the class, and don't have separate
> docstrings.
>
> The instances are created for convenience (especially for users who
> are not familiar with classes).
>
> Josef
>

OK, so if I do help(alpha) for example, here's what I get:

Help on alpha_gen in module scipy.stats.distributions object:

class alpha_gen(rv_continuous)
 |  ## Alpha distribution
 |  ##
 |
 |  Method resolution order:
 |      alpha_gen
 |      rv_continuous
 |      rv_generic
 |      __builtin__.object
 |
 |  Methods inherited from rv_continuous:
...

Am I the only one who thinks this might be confusing to a user (esp. one who
is "not familiar w/ classes")?

Forgive me for persisting, but what's the design rationale here?  In
particular, why is making an instance (which actually appears to be a class
if one asks for help about it) the basis for the API seen as being more
"approachable" than a class - IME, neither is a common programming concept
outside of OO design, so what advantage does one have over the other for an
OO novice?

DG

>
>
> >
> > DG
> >
> > On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com>
> wrote:
> >>
> >> On Thu, May 20, 2010 at 13:22, David Goldsmith <d.l.goldsmith at gmail.com
> >
> >> wrote:
> >> > On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com>
> >> > wrote:
> >> >>
> >> >> <X>_gen is a class and <X> an instance of that class.
> >> >>
> >> >> David H.
> >> >
> >> > So which is a user expected to use?
> >>
> >> The latter.
> >>
> >> --
> >> Robert Kern
> >>
> >> "I have come to believe that the whole world is an enigma, a harmless
> >> enigma that is made terrible by our own mad attempt to interpret it as
> >> though it had an underlying truth."
> >>  -- Umberto Eco
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> uncertainty
> > set is non-empty, even if that set has measure zero.
> >
> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> her
> > lies, prevents mankind from committing a general suicide.  (As
> interpreted
> > by Robert Graves)
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/c7f11c33/attachment.html>

From robert.kern at gmail.com  Thu May 20 17:00:43 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 20 May 2010 16:00:43 -0500
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com> 
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com> 
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com> 
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com> 
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com> 
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
Message-ID: <AANLkTikJGjAG4lf4_D1HqoZnWdBs9m4YqSBEVBNXIy_l@mail.gmail.com>

On Thu, May 20, 2010 at 14:03,  <josef.pktd at gmail.com> wrote:
> On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
>> So then that's actually the one that should be documented?? Or they both
>> should?? (Forgive me if I sound ignorant, but I'm not familiar w/ this API
>> model: I'm use to the library/package/module providing the class, as in
>> "class library," and then the user instantiating (or sub-classing) that as
>> s/he needs; I've never heard of an "instance library.")? Thanks again!
>
> the docstrings are attached to or generated for the classes. The
> instances get the docstrings from the class, and don't have separate
> docstrings.
>
> The instances are created for convenience (especially for users who
> are not familiar with classes).

Not really. It was just the best way to implement the features at the
time with the minimum of duplicated code. I'm pretty sure it was
designed before class methods were introduced. The original design
also did not have the frozen distributions; __call__ was an alias to
.rvs(). The distribution objects act like functions with additional
methods, much like ufuncs do. It's just that now they act more like
factory functions (or class objects) than most normal functions so
things get a little confusing.

If we were to design the system with the tools we have available
today, it would be designed quite differently, I expect.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From josef.pktd at gmail.com  Thu May 20 17:03:51 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 20 May 2010 17:03:51 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
Message-ID: <AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>

On Thu, May 20, 2010 at 4:26 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Thu, May 20, 2010 at 12:03 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>> > So then that's actually the one that should be documented?? Or they both
>> > should?? (Forgive me if I sound ignorant, but I'm not familiar w/ this
>> > API
>> > model: I'm use to the library/package/module providing the class, as in
>> > "class library," and then the user instantiating (or sub-classing) that
>> > as
>> > s/he needs; I've never heard of an "instance library.")? Thanks again!
>>
>> the docstrings are attached to or generated for the classes. The
>> instances get the docstrings from the class, and don't have separate
>> docstrings.
>>
>> The instances are created for convenience (especially for users who
>> are not familiar with classes).
>>
>> Josef
>
> OK, so if I do help(alpha) for example, here's what I get:
>
> Help on alpha_gen in module scipy.stats.distributions object:
>
> class alpha_gen(rv_continuous)
> ?|? ## Alpha distribution
> ?|? ##
> ?|
> ?|? Method resolution order:
> ?|????? alpha_gen
> ?|????? rv_continuous
> ?|????? rv_generic
> ?|????? __builtin__.object
> ?|
> ?|? Methods inherited from rv_continuous:
> ...
>
> Am I the only one who thinks this might be confusing to a user (esp. one who
> is "not familiar w/ classes")?
>
> Forgive me for persisting, but what's the design rationale here?? In
> particular, why is making an instance (which actually appears to be a class
> if one asks for help about it) the basis for the API seen as being more
> "approachable" than a class - IME, neither is a common programming concept
> outside of OO design, so what advantage does one have over the other for an
> OO novice?

The discussion between Pierre and me last August on the scipy-user
mailing list might be informative.

As for why it was written this way: I don't know

Josef

>
> DG
>>
>>
>> >
>> > DG
>> >
>> > On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com>
>> > wrote:
>> >>
>> >> On Thu, May 20, 2010 at 13:22, David Goldsmith
>> >> <d.l.goldsmith at gmail.com>
>> >> wrote:
>> >> > On Thu, May 20, 2010 at 8:12 AM, David Huard <david.huard at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> <X>_gen is a class and <X> an instance of that class.
>> >> >>
>> >> >> David H.
>> >> >
>> >> > So which is a user expected to use?
>> >>
>> >> The latter.
>> >>
>> >> --
>> >> Robert Kern
>> >>
>> >> "I have come to believe that the whole world is an enigma, a harmless
>> >> enigma that is made terrible by our own mad attempt to interpret it as
>> >> though it had an underlying truth."
>> >> ?-- Umberto Eco
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > --
>> > Mathematician: noun, someone who disavows certainty when their
>> > uncertainty
>> > set is non-empty, even if that set has measure zero.
>> >
>> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>> > her
>> > lies, prevents mankind from committing a general suicide. ?(As
>> > interpreted
>> > by Robert Graves)
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From Ralf.Juengling at synopsys.com  Thu May 20 18:26:03 2010
From: Ralf.Juengling at synopsys.com (Ralf Juengling)
Date: Thu, 20 May 2010 15:26:03 -0700
Subject: [SciPy-Dev] numpy.vdot
Message-ID: <ADF81A8D58BECD4A82DA78B2FCABD17CE2260BE8@US01WXMBX1.internal.synopsys.com>

After I learned that numpy.sum accepts an optional dtype argument, I was expecting numpy.vdot would also accept it. Any comments as to why it does not?

Thanks,
Ralf

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/f722efdd/attachment.html>

From d.l.goldsmith at gmail.com  Thu May 20 21:40:36 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 20 May 2010 18:40:36 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTikJGjAG4lf4_D1HqoZnWdBs9m4YqSBEVBNXIy_l@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTikJGjAG4lf4_D1HqoZnWdBs9m4YqSBEVBNXIy_l@mail.gmail.com>
Message-ID: <AANLkTimLDgm5_vpqIS52kRjXW6r1U-a6YXVhkj5aZXnw@mail.gmail.com>

On Thu, May 20, 2010 at 2:00 PM, Robert Kern <robert.kern at gmail.com> wrote:

> On Thu, May 20, 2010 at 14:03,  <josef.pktd at gmail.com> wrote:
> > On Thu, May 20, 2010 at 2:53 PM, David Goldsmith
> > <d.l.goldsmith at gmail.com> wrote:
> >> So then that's actually the one that should be documented?  Or they both
> >> should?  (Forgive me if I sound ignorant, but I'm not familiar w/ this
> API
> >> model: I'm use to the library/package/module providing the class, as in
> >> "class library," and then the user instantiating (or sub-classing) that
> as
> >> s/he needs; I've never heard of an "instance library.")  Thanks again!
> >
> > the docstrings are attached to or generated for the classes. The
> > instances get the docstrings from the class, and don't have separate
> > docstrings.
> >
> > The instances are created for convenience (especially for users who
> > are not familiar with classes).
>
> Not really. It was just the best way to implement the features at the
> time with the minimum of duplicated code. I'm pretty sure it was
> designed before class methods were introduced. The original design
> also did not have the frozen distributions; __call__ was an alias to
> .rvs(). The distribution objects act like functions with additional
> methods, much like ufuncs do. It's just that now they act more like
> factory functions (or class objects) than most normal functions so
> things get a little confusing.
>

Ah, now I understand ("factory functions" *are* something I've heard of, and
vaguely understand...)  IMO, we're going to have to explain all this (and
better) somewhere (stats.distributions looks like a good place) if for no
other reason than Robert says "things get a little confusing" (I'm sure he
isn't confused, but when Robert acknowledges that something isn't obvious,
to me that means it's *far* from obvious) ;-)

UNLESS...

If we were to design the system with the tools we have available
> today, it would be designed quite differently, I expect.
>

...IIRC, from time to time there's chatter about re-factoring scipy - is it
safe to assume that *if* such ever happens, *then* re-factoring this module
is likely to be high on the priorities list?


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/164b58c8/attachment.html>

From d.l.goldsmith at gmail.com  Thu May 20 21:42:38 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 20 May 2010 18:42:38 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
Message-ID: <AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>

On Thu, May 20, 2010 at 2:03 PM, <josef.pktd at gmail.com> wrote:

I knew the issue sounded familiar; I'll have to go back and read that thread
more thoroughly.


> As for why it was written this way: I don't know
>

Well, thanks to Robert, now we do. :-)

DG


>
> Josef
>
> >
> > DG
> >>
> >>
> >> >
> >> > DG
> >> >
> >> > On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Thu, May 20, 2010 at 13:22, David Goldsmith
> >> >> <d.l.goldsmith at gmail.com>
> >> >> wrote:
> >> >> > On Thu, May 20, 2010 at 8:12 AM, David Huard <
> david.huard at gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> <X>_gen is a class and <X> an instance of that class.
> >> >> >>
> >> >> >> David H.
> >> >> >
> >> >> > So which is a user expected to use?
> >> >>
> >> >> The latter.
> >> >>
> >> >> --
> >> >> Robert Kern
> >> >>
> >> >> "I have come to believe that the whole world is an enigma, a harmless
> >> >> enigma that is made terrible by our own mad attempt to interpret it
> as
> >> >> though it had an underlying truth."
> >> >>  -- Umberto Eco
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Mathematician: noun, someone who disavows certainty when their
> >> > uncertainty
> >> > set is non-empty, even if that set has measure zero.
> >> >
> >> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> >> > her
> >> > lies, prevents mankind from committing a general suicide.  (As
> >> > interpreted
> >> > by Robert Graves)
> >> >
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >
> >> >
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> uncertainty
> > set is non-empty, even if that set has measure zero.
> >
> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> her
> > lies, prevents mankind from committing a general suicide.  (As
> interpreted
> > by Robert Graves)
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100520/240bb522/attachment.html>

From pav at iki.fi  Fri May 21 04:46:59 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Fri, 21 May 2010 08:46:59 +0000 (UTC)
Subject: [SciPy-Dev] numpy.vdot
References: <ADF81A8D58BECD4A82DA78B2FCABD17CE2260BE8@US01WXMBX1.internal.synopsys.com>
Message-ID: <ht5ha3$9j7$1@dough.gmane.org>

Thu, 20 May 2010 15:26:03 -0700, Ralf Juengling wrote:
> After I learned that numpy.sum accepts an optional dtype argument, I was
> expecting numpy.vdot would also accept it. Any comments as to why it
> does not?

It's in the end implemented via the underlying BLAS library, which does 
not have many functions with variable-precision accumulators. It would in 
principle be possible to implement a dtype= keyword and fall back to .sum
() when BLAS does not support the accumulator type.

-- 
Pauli Virtanen



From warren.weckesser at enthought.com  Sat May 22 21:27:52 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 22 May 2010 20:27:52 -0500
Subject: [SciPy-Dev] Help with updating scipy.signal docstring
Message-ID: <4BF88498.2030906@enthought.com>

Hi,

I just updated the scipy.signal docstring in the web doc editor.  Now I 
would like to commit this to the trunk.  If I go to the "patch" page 
(i.e. click on "Patch", select only scipy.signal, and then click on 
"Generate patch"), I get a patch whose first few lines are:

--- scipy/signal/__init__.py.old
+++ scipy/signal/__init__.py
@@ -1,3 +1,201 @@
+"""


It looks like it is creating a patch to change 
scipy/signal/__init__.py.  But this docstring is actually in 
scipy/signal/info.py; __init__.py imports __doc__ from info.py.  So, is 
what I am doing actually the correct way to get these changes into trunk?

Warren



From ralf.gommers at googlemail.com  Sun May 23 05:02:02 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 23 May 2010 17:02:02 +0800
Subject: [SciPy-Dev] Help with updating scipy.signal docstring
In-Reply-To: <4BF88498.2030906@enthought.com>
References: <4BF88498.2030906@enthought.com>
Message-ID: <AANLkTim2d5tHVqNoQ_mk3eF8Dp--0_g4384riKfqOi5x@mail.gmail.com>

On Sun, May 23, 2010 at 9:27 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Hi,
>
> I just updated the scipy.signal docstring in the web doc editor.  Now I
> would like to commit this to the trunk.  If I go to the "patch" page
> (i.e. click on "Patch", select only scipy.signal, and then click on
> "Generate patch"), I get a patch whose first few lines are:
>
> --- scipy/signal/__init__.py.old
> +++ scipy/signal/__init__.py
> @@ -1,3 +1,201 @@
> +"""
>
>
> It looks like it is creating a patch to change
> scipy/signal/__init__.py.  But this docstring is actually in
> scipy/signal/info.py; __init__.py imports __doc__ from info.py.  So, is
> what I am doing actually the correct way to get these changes into trunk?
>
> In general yes, you're doing the right thing. But the doc editor does not
recognize manipulations to docstrings by code, in this case the line:
    from info import __doc__
in __init__.py is what messes up patch generation. For these type of
docstrings (a small minority of all docstrings) you have some manual work to
do to reformat the patch, so it's maybe better to make these changes
directly in svn.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100523/bc7873c1/attachment.html>

From warren.weckesser at enthought.com  Sun May 23 09:41:44 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sun, 23 May 2010 08:41:44 -0500
Subject: [SciPy-Dev] What is 'array_like'? Why an underscore instead of a
	hyphen?
Message-ID: <4BF93098.5010205@enthought.com>

<pedantic>
What's up with the use of 'array_like'?  The underscore makes it look 
like an actual python identifier, but as far as I can see, there is no 
such thing.  Why not use 'array-like'?
</pedantic>

Cheers,

Warren



From charlesr.harris at gmail.com  Sun May 23 11:59:42 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Sun, 23 May 2010 09:59:42 -0600
Subject: [SciPy-Dev] What is 'array_like'? Why an underscore instead of
	a hyphen?
In-Reply-To: <4BF93098.5010205@enthought.com>
References: <4BF93098.5010205@enthought.com>
Message-ID: <AANLkTimovXR1iNviiOE_rDggXxRsG9ZFH2NmSsO8X9ql@mail.gmail.com>

On Sun, May 23, 2010 at 7:41 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> <pedantic>
> What's up with the use of 'array_like'?  The underscore makes it look
> like an actual python identifier, but as far as I can see, there is no
> such thing.  Why not use 'array-like'?
> </pedantic>
>
>
Because my shift key was stuck? Think of it as a generic type name. As a
programmer, I'm not clear on how the subtraction of "like" from "array"
should be interpreted ;) Also, please put spaces around operators like "-"
and "+".

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100523/a223d90a/attachment.html>

From warren.weckesser at enthought.com  Mon May 24 12:50:06 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 24 May 2010 11:50:06 -0500
Subject: [SciPy-Dev] Problem building html docs
Message-ID: <4BFAAE3E.50907@enthought.com>

First, many thanks to Ralf Gommers for his work on the documentation 
over the weekend.

I now have a problem building the docs.  Something is wrong with 
doc/source/fftpack.rst.  I think the change in r6407 messed up the 
restructured text.  When I run 'make html' in the doc directory, I get:

<snip>
reading sources... [  0%] 
fftpack                                           
reST markup error:
/Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title 
level inconsistent:

Fast Fourier transforms
=======================
make: *** [html] Error 1



Warren



From d.l.goldsmith at gmail.com  Mon May 24 15:43:19 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 12:43:19 -0700
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <4BFAAE3E.50907@enthought.com>
References: <4BFAAE3E.50907@enthought.com>
Message-ID: <AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>

On Mon, May 24, 2010 at 9:50 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> First, many thanks to Ralf Gommers for his work on the documentation
> over the weekend.
>
> I now have a problem building the docs.  Something is wrong with
> doc/source/fftpack.rst.  I think the change in r6407 messed up the
> restructured text.


It's something more complicated than that (though exactly what I don't
know): a) fftpack.rst is a semi-autogenerated document, and what's there is
not returning any errors in the Wiki, and b) if I'm reading your error msg.
correctly, it's reporting the error is on line 152, but that must be an
autogenerated line cause the rst source only has 79 lines.  So it sounds
like whatever is doing the autogeneration is causing some sort of problem...

DG


> When I run 'make html' in the doc directory, I get:
>
> <snip>
> reading sources... [  0%]
> fftpack
> reST markup error:
> /Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title
> level inconsistent:
>
> Fast Fourier transforms
> =======================
> make: *** [html] Error 1
>
>
>
> Warren
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/63a38dbf/attachment.html>

From warren.weckesser at enthought.com  Mon May 24 16:07:46 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 24 May 2010 15:07:46 -0500
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
References: <4BFAAE3E.50907@enthought.com>
	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
Message-ID: <4BFADC92.6070602@enthought.com>

David Goldsmith wrote:
> On Mon, May 24, 2010 at 9:50 AM, Warren Weckesser 
> <warren.weckesser at enthought.com 
> <mailto:warren.weckesser at enthought.com>> wrote:
>
>     First, many thanks to Ralf Gommers for his work on the documentation
>     over the weekend.
>
>     I now have a problem building the docs.  Something is wrong with
>     doc/source/fftpack.rst.  I think the change in r6407 messed up the
>     restructured text.  
>
>
> It's something more complicated than that (though exactly what I don't 
> know): a) fftpack.rst is a semi-autogenerated document, and what's 
> there is not returning any errors in the Wiki, and b) if I'm reading 
> your error msg. correctly, it's reporting the error is on line 152, 
> but that must be an autogenerated line cause the rst source only has 
> 79 lines.  So it sounds like whatever is doing the autogeneration is 
> causing some sort of problem...
>

I don't know what is or was autogenerated, but in the latest trunk 
(r6410), fftpack.rst has 223 lines.  In r6407, a block of rst was 
inserted in the file.  I suspect something went wrong there.


Warren

> DG
>  
>
>     When I run 'make html' in the doc directory, I get:
>
>     <snip>
>     reading sources... [  0%]
>     fftpack
>     reST markup error:
>     /Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title
>     level inconsistent:
>
>     Fast Fourier transforms
>     =======================
>     make: *** [html] Error 1
>
>
>
>     Warren
>
>     _______________________________________________
>     SciPy-Dev mailing list
>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> -- 
> Mathematician: noun, someone who disavows certainty when their 
> uncertainty set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with 
> her lies, prevents mankind from committing a general suicide.  (As 
> interpreted by Robert Graves)
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From d.l.goldsmith at gmail.com  Mon May 24 16:14:20 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 13:14:20 -0700
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <4BFADC92.6070602@enthought.com>
References: <4BFAAE3E.50907@enthought.com>
	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
	<4BFADC92.6070602@enthought.com>
Message-ID: <AANLkTimwLoEYsm0IZW-ht-w4sKkx9wOphlc66hbbJAYH@mail.gmail.com>

On Mon, May 24, 2010 at 1:07 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> David Goldsmith wrote:
> > On Mon, May 24, 2010 at 9:50 AM, Warren Weckesser
> > <warren.weckesser at enthought.com
> > <mailto:warren.weckesser at enthought.com>> wrote:
> >
> >     First, many thanks to Ralf Gommers for his work on the documentation
> >     over the weekend.
> >
> >     I now have a problem building the docs.  Something is wrong with
> >     doc/source/fftpack.rst.  I think the change in r6407 messed up the
> >     restructured text.
> >
> >
> > It's something more complicated than that (though exactly what I don't
> > know): a) fftpack.rst is a semi-autogenerated document, and what's
> > there is not returning any errors in the Wiki, and b) if I'm reading
> > your error msg. correctly, it's reporting the error is on line 152,
> > but that must be an autogenerated line cause the rst source only has
> > 79 lines.  So it sounds like whatever is doing the autogeneration is
> > causing some sort of problem...
> >
>
> I don't know what is or was autogenerated, but in the latest trunk
> (r6410), fftpack.rst has 223 lines.  In r6407, a block of rst was
> inserted in the file.  I suspect something went wrong there.
>

Anyone have an explanation why it's not in the Wiki yet?

DG


>
>
> Warren
>
> > DG
> >
> >
> >     When I run 'make html' in the doc directory, I get:
> >
> >     <snip>
> >     reading sources... [  0%]
> >     fftpack
> >     reST markup error:
> >     /Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title
> >     level inconsistent:
> >
> >     Fast Fourier transforms
> >     =======================
> >     make: *** [html] Error 1
> >
> >
> >
> >     Warren
> >
> >     _______________________________________________
> >     SciPy-Dev mailing list
> >     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
> >     http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> > uncertainty set is non-empty, even if that set has measure zero.
> >
> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> > her lies, prevents mankind from committing a general suicide.  (As
> > interpreted by Robert Graves)
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/381fe952/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 24 17:45:22 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 14:45:22 -0700
Subject: [SciPy-Dev] [Announcement] Summer Marathon weekly Skypecon
Message-ID: <AANLkTimYfVbz1T2MXFa_87NrphQ4stGHwv81tfnCyYSC@mail.gmail.com>

Welcome to the first 2010 Summer Doc Marathon Announcement!  Like last
summer, we'll be holding a weekly Skypecon to discuss issues, plan the
coming week, etc., etc.  For now, we've scheduled it for Fridays, noon
Eastern Daylight Time (GMT - 5 unless I am mistaken); if, among people who
intend to participate regularly, there's overwhelming sentiment that this is
a bad time, we'll try to negotiate a better time and/or make the time
variable from week to week (though this is far from preferable).  I'll be
hosting, so be sure I have your Skype name before Friday; also, email me any
agenda items you have ASAP - I'll try to post a draft agenda by 3pm EDT
Thursdays.  Questions?  Just email me! :-)

David Goldsmith
Olympia, WA
Editor pro tem

-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/3f31d14d/attachment.html>

From warren.weckesser at enthought.com  Mon May 24 18:56:57 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 24 May 2010 17:56:57 -0500
Subject: [SciPy-Dev] preparing for scipy 0.8 release
In-Reply-To: <l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
References: <u2jdde7764a1004250405x26e33f46i365e8f4679c382b5@mail.gmail.com>	<hr2gkq$ois$1@dough.gmane.org>	<q2ndde7764a1004260441qbeb3c920h96a2a20e384e553c@mail.gmail.com>
	<l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
Message-ID: <4BFB0439.9060008@enthought.com>

Ralf Gommers wrote:
>
>
> On Mon, Apr 26, 2010 at 7:41 PM, Ralf Gommers 
> <ralf.gommers at googlemail.com <mailto:ralf.gommers at googlemail.com>> wrote:
>
>
>     On Mon, Apr 26, 2010 at 6:44 AM, Pauli Virtanen <pav+sp at iki.fi
>     <mailto:pav%2Bsp at iki.fi>> wrote:
>
>         Sun, 25 Apr 2010 19:05:27 +0800, Ralf Gommers wrote:
>
>         As David said, we'll need at least Numpy >= 1.4, due to use of
>         npymath.
>
>         It might be difficult to go for Python 3 support if we want to
>         have
>         backwards compatibility with Numpy 1.4, unless we go really
>         ugly and
>         start duplicating some of the utility functions inside Scipy.
>         But from a
>         maintenance POV that might be less of a burden than having to
>         maintain
>         0.8.x and 0.9.x simultaneously...
>          
>
>     The number of fixes in the 0.7 series is small, so I'm not sure if
>     the maintenance burden is really that high (besides possibly
>     having to do an extra maintenance release). It depends on how long
>     you'd want to keep compatibility with numpy 1.4. Anyway, both
>     options sound better than having no compatible release at all.
>
>
> I thought about it some more, and a backwards compatible release with 
> numpy 1.4.1 that is also compatible with numpy 2.0 is not even 
> possible. And compatibility with 1.4.0 is not nearly as useful. So two 
> releases would really make sense: 0.8 built against numpy 1.4.1 and 
> 0.9 against numpy 2.0 with py3k compatibility.
>
> Here's a proposal for the release schedule:
> 30/05: create 0.8.x branch, beta available, trunk open to add py3k 
> compatibility
> 11/06: 0.8 release candidate 1
> 22/06: 0.8 release
>
> 15/08: create 0.9.x branch, first beta
> 22/08: 0.9 release candidate 1
> 01/09: 0.9 release
>
> How does this sound?


I think that is still the plan, correct?  If so, now is probably a good 
time to remind people that the 0.8.x branch is only a week away.

I assume that the branch also corresponds to a feature freeze (is that 
correct?), so if y'all have things you want to get into 0.8, now is the 
time.

Warren


>
> Ralf
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From d.l.goldsmith at gmail.com  Mon May 24 19:58:06 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 16:58:06 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
Message-ID: <AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>

OK, having looked at the source code (duh), I have a better idea what's
going on; correct me if I'm wrong: the idea was to make each distribution
generic up to its specification parameters, and immediately available upon
importing scipy.stats (i.e., no need to explicitly import distributions, no
need for the user to create an instance of the desired distribution).  The
former suggested the object model (i.e., classes) be used, the latter
required such classes to be instantiated at module scope on import of
distributions (which import scipy.stats does).  With this in mind, I'm
comfortable w/ the status quo as far as the code is concerned, supplemented
w/ an explanation of this (which I'll write, unless someone feels I won't do
it justice - don't be shy about telling me so, I won't take it personally)
in (module) distribution's docstring.  I do feel, however, that it would be
best if the Wiki didn't think that the instances required/possessed
docstrings, or at least warned unsuspecting editors that editing those
objects' docstrings is a waste of time; accordingly, I'll be filing a
ticket...

DG

On Thu, May 20, 2010 at 6:42 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> On Thu, May 20, 2010 at 2:03 PM, <josef.pktd at gmail.com> wrote:
>
> I knew the issue sounded familiar; I'll have to go back and read that
> thread more thoroughly.
>
>
>> As for why it was written this way: I don't know
>>
>
> Well, thanks to Robert, now we do. :-)
>
> DG
>
>
>>
>> Josef
>>
>> >
>> > DG
>> >>
>> >>
>> >> >
>> >> > DG
>> >> >
>> >> > On Thu, May 20, 2010 at 11:24 AM, Robert Kern <robert.kern at gmail.com
>> >
>> >> > wrote:
>> >> >>
>> >> >> On Thu, May 20, 2010 at 13:22, David Goldsmith
>> >> >> <d.l.goldsmith at gmail.com>
>> >> >> wrote:
>> >> >> > On Thu, May 20, 2010 at 8:12 AM, David Huard <
>> david.huard at gmail.com>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> <X>_gen is a class and <X> an instance of that class.
>> >> >> >>
>> >> >> >> David H.
>> >> >> >
>> >> >> > So which is a user expected to use?
>> >> >>
>> >> >> The latter.
>> >> >>
>> >> >> --
>> >> >> Robert Kern
>> >> >>
>> >> >> "I have come to believe that the whole world is an enigma, a
>> harmless
>> >> >> enigma that is made terrible by our own mad attempt to interpret it
>> as
>> >> >> though it had an underlying truth."
>> >> >>  -- Umberto Eco
>> >> >> _______________________________________________
>> >> >> SciPy-Dev mailing list
>> >> >> SciPy-Dev at scipy.org
>> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Mathematician: noun, someone who disavows certainty when their
>> >> > uncertainty
>> >> > set is non-empty, even if that set has measure zero.
>> >> >
>> >> > Hope: noun, that delusive spirit which escaped Pandora's jar and,
>> with
>> >> > her
>> >> > lies, prevents mankind from committing a general suicide.  (As
>> >> > interpreted
>> >> > by Robert Graves)
>> >> >
>> >> > _______________________________________________
>> >> > SciPy-Dev mailing list
>> >> > SciPy-Dev at scipy.org
>> >> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >> >
>> >> >
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > --
>> > Mathematician: noun, someone who disavows certainty when their
>> uncertainty
>> > set is non-empty, even if that set has measure zero.
>> >
>> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>> her
>> > lies, prevents mankind from committing a general suicide.  (As
>> interpreted
>> > by Robert Graves)
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide.  (As interpreted
> by Robert Graves)
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/ace76231/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 24 20:13:16 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 17:13:16 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
Message-ID: <AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>

On Mon, May 24, 2010 at 4:58 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> OK, having looked at the source code (duh), I have a better idea what's
> going on; correct me if I'm wrong: the idea was to make each distribution
> generic up to its specification parameters, and immediately available upon
> importing scipy.stats (i.e., no need to explicitly import distributions, no
> need for the user to create an instance of the desired distribution).  The
> former suggested the object model (i.e., classes) be used, the latter
> required such classes to be instantiated at module scope on import of
> distributions (which import scipy.stats does).  With this in mind, I'm
> comfortable w/ the status quo as far as the code is concerned, supplemented
> w/ an explanation of this (which I'll write, unless someone feels I won't do
> it justice - don't be shy about telling me so, I won't take it personally)
> in (module) distribution's docstring.  I do feel, however, that it would be
> best if the Wiki didn't think that the instances required/possessed
> docstrings, or at least warned unsuspecting editors that editing those
> objects' docstrings is a waste of time; accordingly, I'll be filing a
> ticket...
>
> DG


Duh (again) I'll just change the status of each instance object to
Unimportant.

DG


>
>
> On Thu, May 20, 2010 at 6:42 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>> On Thu, May 20, 2010 at 2:03 PM, <josef.pktd at gmail.com> wrote:
>>
>> I knew the issue sounded familiar; I'll have to go back and read that
>> thread more thoroughly.
>>
>>
>>> As for why it was written this way: I don't know
>>>
>>
>> Well, thanks to Robert, now we do. :-)
>>
>> DG
>>
>>
>>>
>>> Josef
>>>
>>> >
>>> > DG
>>> >>
>>> >>
>>> >> >
>>> >> > DG
>>> >> >
>>> >> > On Thu, May 20, 2010 at 11:24 AM, Robert Kern <
>>> robert.kern at gmail.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> On Thu, May 20, 2010 at 13:22, David Goldsmith
>>> >> >> <d.l.goldsmith at gmail.com>
>>> >> >> wrote:
>>> >> >> > On Thu, May 20, 2010 at 8:12 AM, David Huard <
>>> david.huard at gmail.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> <X>_gen is a class and <X> an instance of that class.
>>> >> >> >>
>>> >> >> >> David H.
>>> >> >> >
>>> >> >> > So which is a user expected to use?
>>> >> >>
>>> >> >> The latter.
>>> >> >>
>>> >> >> --
>>> >> >> Robert Kern
>>> >> >>
>>> >> >> "I have come to believe that the whole world is an enigma, a
>>> harmless
>>> >> >> enigma that is made terrible by our own mad attempt to interpret it
>>> as
>>> >> >> though it had an underlying truth."
>>> >> >>  -- Umberto Eco
>>> >> >> _______________________________________________
>>> >> >> SciPy-Dev mailing list
>>> >> >> SciPy-Dev at scipy.org
>>> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Mathematician: noun, someone who disavows certainty when their
>>> >> > uncertainty
>>> >> > set is non-empty, even if that set has measure zero.
>>> >> >
>>> >> > Hope: noun, that delusive spirit which escaped Pandora's jar and,
>>> with
>>> >> > her
>>> >> > lies, prevents mankind from committing a general suicide.  (As
>>> >> > interpreted
>>> >> > by Robert Graves)
>>> >> >
>>> >> > _______________________________________________
>>> >> > SciPy-Dev mailing list
>>> >> > SciPy-Dev at scipy.org
>>> >> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >> >
>>> >> >
>>> >> _______________________________________________
>>> >> SciPy-Dev mailing list
>>> >> SciPy-Dev at scipy.org
>>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> >
>>> >
>>> > --
>>> > Mathematician: noun, someone who disavows certainty when their
>>> uncertainty
>>> > set is non-empty, even if that set has measure zero.
>>> >
>>> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>>> her
>>> > lies, prevents mankind from committing a general suicide.  (As
>>> interpreted
>>> > by Robert Graves)
>>> >
>>> > _______________________________________________
>>> > SciPy-Dev mailing list
>>> > SciPy-Dev at scipy.org
>>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>>> >
>>> >
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>
>>
>>
>> --
>> Mathematician: noun, someone who disavows certainty when their uncertainty
>> set is non-empty, even if that set has measure zero.
>>
>> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
>> lies, prevents mankind from committing a general suicide.  (As interpreted
>> by Robert Graves)
>>
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide.  (As interpreted
> by Robert Graves)
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/a89dbce0/attachment.html>

From ralf.gommers at googlemail.com  Mon May 24 20:15:47 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 25 May 2010 08:15:47 +0800
Subject: [SciPy-Dev] preparing for scipy 0.8 release
In-Reply-To: <4BFB0439.9060008@enthought.com>
References: <u2jdde7764a1004250405x26e33f46i365e8f4679c382b5@mail.gmail.com>
	<hr2gkq$ois$1@dough.gmane.org>
	<q2ndde7764a1004260441qbeb3c920h96a2a20e384e553c@mail.gmail.com>
	<l2pdde7764a1004270630z1a037b4fob56c844d0c2ea89b@mail.gmail.com>
	<4BFB0439.9060008@enthought.com>
Message-ID: <AANLkTilkmHPvbkNR7cB9qPcy6Q2oq1GHelXhSvQFRGgR@mail.gmail.com>

On Tue, May 25, 2010 at 6:56 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Ralf Gommers wrote:
> > I thought about it some more, and a backwards compatible release with
> > numpy 1.4.1 that is also compatible with numpy 2.0 is not even
> > possible. And compatibility with 1.4.0 is not nearly as useful. So two
> > releases would really make sense: 0.8 built against numpy 1.4.1 and
> > 0.9 against numpy 2.0 with py3k compatibility.
> >
> > Here's a proposal for the release schedule:
> > 30/05: create 0.8.x branch, beta available, trunk open to add py3k
> > compatibility
> > 11/06: 0.8 release candidate 1
> > 22/06: 0.8 release
> >
> > 15/08: create 0.9.x branch, first beta
> > 22/08: 0.9 release candidate 1
> > 01/09: 0.9 release
> >
> > How does this sound?
>
>
> I think that is still the plan, correct?  If so, now is probably a good
> time to remind people that the 0.8.x branch is only a week away.
>
> I assume that the branch also corresponds to a feature freeze (is that
> correct?), so if y'all have things you want to get into 0.8, now is the
> time.
>
> Still the plan, thanks for the reminder Warren. Please get your new
features in by Saturday, on Sunday I'll create the 0.8 branch.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/67a6e575/attachment.html>

From ralf.gommers at googlemail.com  Mon May 24 20:26:11 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 25 May 2010 08:26:11 +0800
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimvioGZyOpo5PDCq1sPVZRMTKFNWP90QNcT2bl7@mail.gmail.com>
	<AANLkTiny6aLg5h-d9Jm-7UH9g3r1h51iMGgeByJIby-H@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
Message-ID: <AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>

On Tue, May 25, 2010 at 8:13 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> On Mon, May 24, 2010 at 4:58 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>> OK, having looked at the source code (duh), I have a better idea what's
>> going on; correct me if I'm wrong: the idea was to make each distribution
>> generic up to its specification parameters, and immediately available upon
>> importing scipy.stats (i.e., no need to explicitly import distributions, no
>> need for the user to create an instance of the desired distribution).  The
>> former suggested the object model (i.e., classes) be used, the latter
>> required such classes to be instantiated at module scope on import of
>> distributions (which import scipy.stats does).  With this in mind, I'm
>> comfortable w/ the status quo as far as the code is concerned, supplemented
>> w/ an explanation of this (which I'll write, unless someone feels I won't do
>> it justice - don't be shy about telling me so, I won't take it personally)
>> in (module) distribution's docstring.  I do feel, however, that it would be
>> best if the Wiki didn't think that the instances required/possessed
>> docstrings, or at least warned unsuspecting editors that editing those
>> objects' docstrings is a waste of time; accordingly, I'll be filing a
>> ticket...
>>
>> DG
>
>
> Duh (again) I'll just change the status of each instance object to
> Unimportant.
>
> That doesn't fix everything, the x_gen classes should also not be edited
right now. Plus they're not really unimportant. A new way to 'lock' pages
would really be helpful.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/6a9644bb/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 24 20:34:35 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 24 May 2010 17:34:35 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
Message-ID: <AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>

On Mon, May 24, 2010 at 5:26 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Tue, May 25, 2010 at 8:13 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>> On Mon, May 24, 2010 at 4:58 PM, David Goldsmith <d.l.goldsmith at gmail.com
>> > wrote:
>>
>>> OK, having looked at the source code (duh), I have a better idea what's
>>> going on; correct me if I'm wrong: the idea was to make each distribution
>>> generic up to its specification parameters, and immediately available upon
>>> importing scipy.stats (i.e., no need to explicitly import distributions, no
>>> need for the user to create an instance of the desired distribution).  The
>>> former suggested the object model (i.e., classes) be used, the latter
>>> required such classes to be instantiated at module scope on import of
>>> distributions (which import scipy.stats does).  With this in mind, I'm
>>> comfortable w/ the status quo as far as the code is concerned, supplemented
>>> w/ an explanation of this (which I'll write, unless someone feels I won't do
>>> it justice - don't be shy about telling me so, I won't take it personally)
>>> in (module) distribution's docstring.  I do feel, however, that it would be
>>> best if the Wiki didn't think that the instances required/possessed
>>> docstrings, or at least warned unsuspecting editors that editing those
>>> objects' docstrings is a waste of time; accordingly, I'll be filing a
>>> ticket...
>>>
>>> DG
>>
>>
>> Duh (again) I'll just change the status of each instance object to
>> Unimportant.
>>
>> That doesn't fix everything, the x_gen classes should also not be edited
> right now.
>

Why?


> Plus they're not really unimportant.
>

Why not?  They're not returned by Python's help system.  (See earlier this
same thread.)


> A new way to 'lock' pages would really be helpful.
>

Agreed.

DG

>
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100524/4a7fe78d/attachment.html>

From josef.pktd at gmail.com  Mon May 24 23:25:36 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 24 May 2010 23:25:36 -0400
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <4BFADC92.6070602@enthought.com>
References: <4BFAAE3E.50907@enthought.com>
	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
	<4BFADC92.6070602@enthought.com>
Message-ID: <AANLkTilVg06cvhONtq65OAecOojI774mOtebQHsKT3kf@mail.gmail.com>

On Mon, May 24, 2010 at 4:07 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> David Goldsmith wrote:
>> On Mon, May 24, 2010 at 9:50 AM, Warren Weckesser
>> <warren.weckesser at enthought.com
>> <mailto:warren.weckesser at enthought.com>> wrote:
>>
>> ? ? First, many thanks to Ralf Gommers for his work on the documentation
>> ? ? over the weekend.
>>
>> ? ? I now have a problem building the docs. ?Something is wrong with
>> ? ? doc/source/fftpack.rst. ?I think the change in r6407 messed up the
>> ? ? restructured text.
>>
>>
>> It's something more complicated than that (though exactly what I don't
>> know): a) fftpack.rst is a semi-autogenerated document, and what's
>> there is not returning any errors in the Wiki, and b) if I'm reading
>> your error msg. correctly, it's reporting the error is on line 152,
>> but that must be an autogenerated line cause the rst source only has
>> 79 lines. ?So it sounds like whatever is doing the autogeneration is
>> causing some sort of problem...
>>
>
> I don't know what is or was autogenerated, but in the latest trunk
> (r6410), fftpack.rst has 223 lines. ?In r6407, a block of rst was
> inserted in the file. ?I suspect something went wrong there.

There is a mix up between the tutorial rst page and the module rst page
The inserted block is a new stub page in the tutorial and was not
supposed to be copied to the fftpack source package, but instead to
the tutorial directory.

http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/
shows the correct txt, but clicking source links to the module rst

I added new tutorial/fftpack.rst  in the doc editor  to rescue the tex
formulas from the doc string.

The way it is copied the header underlines don't match up, which is a
fatal error for rst.

Warren, a fix would be to copy the new tutorial  fftpack.rst to the
tutorial folder and delete the inserted block from the module
fftpack.rst

That's my interpretation of the situation,

Josef



>
>
> Warren
>
>> DG
>>
>>
>> ? ? When I run 'make html' in the doc directory, I get:
>>
>> ? ? <snip>
>> ? ? reading sources... [ ?0%]
>> ? ? fftpack
>> ? ? reST markup error:
>> ? ? /Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title
>> ? ? level inconsistent:
>>
>> ? ? Fast Fourier transforms
>> ? ? =======================
>> ? ? make: *** [html] Error 1
>>
>>
>>
>> ? ? Warren
>>
>> ? ? _______________________________________________
>> ? ? SciPy-Dev mailing list
>> ? ? SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>> ? ? http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>
>>
>>
>> --
>> Mathematician: noun, someone who disavows certainty when their
>> uncertainty set is non-empty, even if that set has measure zero.
>>
>> Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>> her lies, prevents mankind from committing a general suicide. ?(As
>> interpreted by Robert Graves)
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From warren.weckesser at enthought.com  Tue May 25 00:46:20 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 24 May 2010 23:46:20 -0500
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <AANLkTilVg06cvhONtq65OAecOojI774mOtebQHsKT3kf@mail.gmail.com>
References: <4BFAAE3E.50907@enthought.com>	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>	<4BFADC92.6070602@enthought.com>
	<AANLkTilVg06cvhONtq65OAecOojI774mOtebQHsKT3kf@mail.gmail.com>
Message-ID: <4BFB561C.3000300@enthought.com>

josef.pktd at gmail.com wrote:
> On Mon, May 24, 2010 at 4:07 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> David Goldsmith wrote:
>>     
>>> On Mon, May 24, 2010 at 9:50 AM, Warren Weckesser
>>> <warren.weckesser at enthought.com
>>> <mailto:warren.weckesser at enthought.com>> wrote:
>>>
>>>     First, many thanks to Ralf Gommers for his work on the documentation
>>>     over the weekend.
>>>
>>>     I now have a problem building the docs.  Something is wrong with
>>>     doc/source/fftpack.rst.  I think the change in r6407 messed up the
>>>     restructured text.
>>>
>>>
>>> It's something more complicated than that (though exactly what I don't
>>> know): a) fftpack.rst is a semi-autogenerated document, and what's
>>> there is not returning any errors in the Wiki, and b) if I'm reading
>>> your error msg. correctly, it's reporting the error is on line 152,
>>> but that must be an autogenerated line cause the rst source only has
>>> 79 lines.  So it sounds like whatever is doing the autogeneration is
>>> causing some sort of problem...
>>>
>>>       
>> I don't know what is or was autogenerated, but in the latest trunk
>> (r6410), fftpack.rst has 223 lines.  In r6407, a block of rst was
>> inserted in the file.  I suspect something went wrong there.
>>     
>
> There is a mix up between the tutorial rst page and the module rst page
> The inserted block is a new stub page in the tutorial and was not
> supposed to be copied to the fftpack source package, but instead to
> the tutorial directory.
>
> http://docs.scipy.org/scipy/docs/scipy-docs/tutorial/fftpack.rst/
> shows the correct txt, but clicking source links to the module rst
>
> I added new tutorial/fftpack.rst  in the doc editor  to rescue the tex
> formulas from the doc string.
>
> The way it is copied the header underlines don't match up, which is a
> fatal error for rst.
>
> Warren, a fix would be to copy the new tutorial  fftpack.rst to the
> tutorial folder and delete the inserted block from the module
> fftpack.rst
>   


Done (via svn, r6411).  Running "make html" now generates an assortment 
of errors and over 500 warnings, but at least it runs to completion. :)

Warren


> That's my interpretation of the situation,
>
> Josef
>
>
>
>   
>> Warren
>>
>>     
>>> DG
>>>
>>>
>>>     When I run 'make html' in the doc directory, I get:
>>>
>>>     <snip>
>>>     reading sources... [  0%]
>>>     fftpack
>>>     reST markup error:
>>>     /Users/warren/scipy_src/doc/source/fftpack.rst:152: (SEVERE/4) Title
>>>     level inconsistent:
>>>
>>>     Fast Fourier transforms
>>>     =======================
>>>     make: *** [html] Error 1
>>>
>>>
>>>
>>>     Warren
>>>
>>>     _______________________________________________
>>>     SciPy-Dev mailing list
>>>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>>>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>
>>>
>>>
>>> --
>>> Mathematician: noun, someone who disavows certainty when their
>>> uncertainty set is non-empty, even if that set has measure zero.
>>>
>>> Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>>> her lies, prevents mankind from committing a general suicide.  (As
>>> interpreted by Robert Graves)
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> SciPy-Dev mailing list
>>> SciPy-Dev at scipy.org
>>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>>
>>>       
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>>     
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From ralf.gommers at googlemail.com  Tue May 25 11:37:13 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 25 May 2010 23:37:13 +0800
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <4BFB561C.3000300@enthought.com>
References: <4BFAAE3E.50907@enthought.com>
	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
	<4BFADC92.6070602@enthought.com>
	<AANLkTilVg06cvhONtq65OAecOojI774mOtebQHsKT3kf@mail.gmail.com>
	<4BFB561C.3000300@enthought.com>
Message-ID: <AANLkTilE1V-MrruGWDQHgVyfbiWB0DVT1DSmumkB2GVa@mail.gmail.com>

On Tue, May 25, 2010 at 12:46 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

>  <josef.pktd at gmail.com>
> Done (via svn, r6411).  Running "make html" now generates an assortment
> of errors and over 500 warnings, but at least it runs to completion. :)
>
> Thanks for fixing that Warren. Guess in this case it wasn't enough that the
patch looks fine and applied cleanly.

By the way, does anyone have a reasonable way with git to get the sphinxext
stuff from numpy that svn pulls in via externals? This is the reason that
the docs don't build out of the box in a git repo. And can I add
/doc/sphinxext to .gitignore?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/46709c2e/attachment.html>

From ralf.gommers at googlemail.com  Tue May 25 11:54:00 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 25 May 2010 23:54:00 +0800
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTin4YLmSS4RvBLTl-l2gDWTNX2G40CYx4HMf2EHk@mail.gmail.com>
	<AANLkTinfW-0wfHfGnoKmj4o3_KVNYKEjorOTrNK8Jmlb@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
Message-ID: <AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>

On Tue, May 25, 2010 at 8:34 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> On Mon, May 24, 2010 at 5:26 PM, Ralf Gommers <ralf.gommers at googlemail.com
> > wrote:
>
>>
>>
>> On Tue, May 25, 2010 at 8:13 AM, David Goldsmith <d.l.goldsmith at gmail.com
>> > wrote:
>>
>>> On Mon, May 24, 2010 at 4:58 PM, David Goldsmith <
>>> d.l.goldsmith at gmail.com> wrote:
>>>
>>>> OK, having looked at the source code (duh), I have a better idea what's
>>>> going on; correct me if I'm wrong: the idea was to make each distribution
>>>> generic up to its specification parameters, and immediately available upon
>>>> importing scipy.stats (i.e., no need to explicitly import distributions, no
>>>> need for the user to create an instance of the desired distribution).  The
>>>> former suggested the object model (i.e., classes) be used, the latter
>>>> required such classes to be instantiated at module scope on import of
>>>> distributions (which import scipy.stats does).  With this in mind, I'm
>>>> comfortable w/ the status quo as far as the code is concerned, supplemented
>>>> w/ an explanation of this (which I'll write, unless someone feels I won't do
>>>> it justice - don't be shy about telling me so, I won't take it personally)
>>>> in (module) distribution's docstring.  I do feel, however, that it would be
>>>> best if the Wiki didn't think that the instances required/possessed
>>>> docstrings, or at least warned unsuspecting editors that editing those
>>>> objects' docstrings is a waste of time; accordingly, I'll be filing a
>>>> ticket...
>>>>
>>>> DG
>>>
>>>
>>> Duh (again) I'll just change the status of each instance object to
>>> Unimportant.
>>>
>>> That doesn't fix everything, the x_gen classes should also not be edited
>> right now.
>>
>
> Why?
>

Because the patch generation doesn't work. Just last week we had the same
discussion about the Polynomial docstrings.

>
>
>> Plus they're not really unimportant.
>>
>
> Why not?  They're not returned by Python's help system.  (See earlier this
> same thread.)
>

Compare "help(alpha)" with "print alpha.__doc__" - help() is broken imho.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/ef549c40/attachment.html>

From d.l.goldsmith at gmail.com  Tue May 25 12:47:22 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 25 May 2010 09:47:22 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTim3DJf3kNbZ7ZHIpEB33lW2lDJV08EeMb3yQ2R6@mail.gmail.com>
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
Message-ID: <AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>

On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

> That doesn't fix everything, the x_gen classes should also not be edited
> right now.
>
>>
>> Why?
>>
>
> Because the patch generation doesn't work. Just last week we had the same
> discussion about the Polynomial docstrings.
>

But that was about classes being generated from text templates - you're
saying the same problem applies?  What's it gonna take to fix the "patch
generation"?  We're concerned 'cause SciPy is the intended focus of the
Marathon this summer (yes, I know, there's plenty of other stuff to keep us
occupied, but inquiring minds want to know).


>  Plus they're not really unimportant.
>>
>>>
>> Why not?  They're not returned by Python's help system.  (See earlier this
>> same thread.)
>>
>
> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken imho.
>

Care to elaborate?  ("Where I come from" help is the proper idiom - I've
never heard of anyone using, nor being told to use, print .__doc__; your
"ho" - that help is broken - strikes me as pretty strange).

DG


>
> Cheers,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/b198a8ff/attachment.html>

From robert.kern at gmail.com  Tue May 25 14:04:31 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Tue, 25 May 2010 14:04:31 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com> 
	<AANLkTin0ZASpIpfW8919TodoI79qwYQuZTQwMQdeOhZd@mail.gmail.com> 
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com> 
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com> 
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com> 
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com> 
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com> 
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com> 
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com> 
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
Message-ID: <AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>

On Tue, May 25, 2010 at 12:47, David Goldsmith <d.l.goldsmith at gmail.com> wrote:
> On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers <ralf.gommers at googlemail.com>
> wrote:

>>> ?Plus they're not really unimportant.
>>>
>>> Why not?? They're not returned by Python's help system.? (See earlier
>>> this same thread.)
>>
>> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken imho.
>
> Care to elaborate? ("Where I come from" help is the proper idiom - I've
> never heard of anyone using, nor being told to use, print .__doc__; your
> "ho" - that help is broken - strikes me as pretty strange).

help() is broken in this case because it does not display the .__doc__
attribute that is present. Yes, help() is idiomatic. That doesn't mean
its behavior in this case is not broken. Nor does it mean that the
text in the .__doc__ attributes are Unimportant for the docstring
editing workflow. They just happen to be unavailable to the web
docstring editor for technical reasons. If you want to mark them
Unimportant just as a workaround, that's fine. But if you are keeping
track of items to work on this summer, these are important things to
do. You will just have to do it manually.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From d.l.goldsmith at gmail.com  Tue May 25 15:52:21 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 25 May 2010 12:52:21 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTinUQ-3ByGvR8LV7tndSgFMxtnFwhv1P9iREudT3@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
	<AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
Message-ID: <AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>

On Tue, May 25, 2010 at 11:04 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On Tue, May 25, 2010 at 12:47, David Goldsmith <d.l.goldsmith at gmail.com>
> wrote:
> > On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers <
> ralf.gommers at googlemail.com>
> > wrote:
>
> >>>  Plus they're not really unimportant.
> >>>
> >>> Why not?  They're not returned by Python's help system.  (See earlier
> >>> this same thread.)
> >>
> >> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken
> imho.
> >
> > Care to elaborate? ("Where I come from" help is the proper idiom - I've
> > never heard of anyone using, nor being told to use, print .__doc__; your
> > "ho" - that help is broken - strikes me as pretty strange).
>
> help() is broken in this case because it does not display the .__doc__
> attribute that is present. Yes, help() is idiomatic. That doesn't mean
> its behavior in this case is not broken. Nor does it mean that the
> text in the .__doc__ attributes are Unimportant for the docstring
> editing workflow. They just happen to be unavailable to the web
> docstring editor for technical reasons.


Perhaps the origin of this thread has been forgotten:

help(alpha) returns:

>>> help(alpha)
Help on alpha_gen in module scipy.stats.distributions object:

class alpha_gen(rv_continuous)
 |  ## Alpha distribution
:
:

help(alpha_gen) returns:

>>> help(alpha_gen)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'alpha_gen' is not defined

But (in the Wiki) scipy.stats.distributions.alpha is "full," whereas
scipy.stats.distributions.alpha_gen is empty (but for automatically
generated content): help and the doc Wiki appear to exhibit the "transpose"
of one another - I don't know "which one" is "broken" in this situation, but
obviously something is.

At what level is help broken: the scipy level or the Python level?  If help
is simply an alias for print .__doc__, why precisely is this happening?  Is
this an undiagnosed breakage (in the sense that only the symptom(s), but
neither the cause(s) nor the cure(s) are known)?

Looking back on this thread, since <X> is the thing users are intended to
use, it sounds like the docstring _should_ be associated with <X>, not
<X>_gen, so I guess the Wiki is showing the docstring in the "right" place,
but why does help associate the docstring with <X>_gen?  And if the
docstring for <X> is consequently important, is the docstring for <X>_gen
Unimportant (since its object "should" never be used explicitly)?  If its
docstring is also important, please explain why.

Thanks.

DG


> If you want to mark them
> Unimportant just as a workaround, that's fine. But if you are keeping
> track of items to work on this summer, these are important things to
> do. You will just have to do it manually.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/092ebbad/attachment.html>

From josef.pktd at gmail.com  Tue May 25 16:08:41 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 25 May 2010 16:08:41 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTilTujojNS3LPe9WOnv5GQJcOo3m4lbUPyaPxYmu@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
	<AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
	<AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>
Message-ID: <AANLkTinmMfGWkCLgryszgcY-XMnELzRsupc0405LZjWO@mail.gmail.com>

On Tue, May 25, 2010 at 3:52 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Tue, May 25, 2010 at 11:04 AM, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> On Tue, May 25, 2010 at 12:47, David Goldsmith <d.l.goldsmith at gmail.com>
>> wrote:
>> > On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers
>> > <ralf.gommers at googlemail.com>
>> > wrote:
>>
>> >>> ?Plus they're not really unimportant.
>> >>>
>> >>> Why not?? They're not returned by Python's help system.? (See earlier
>> >>> this same thread.)
>> >>
>> >> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken
>> >> imho.
>> >
>> > Care to elaborate? ("Where I come from" help is the proper idiom - I've
>> > never heard of anyone using, nor being told to use, print .__doc__; your
>> > "ho" - that help is broken - strikes me as pretty strange).
>>
>> help() is broken in this case because it does not display the .__doc__
>> attribute that is present. Yes, help() is idiomatic. That doesn't mean
>> its behavior in this case is not broken. Nor does it mean that the
>> text in the .__doc__ attributes are Unimportant for the docstring
>> editing workflow. They just happen to be unavailable to the web
>> docstring editor for technical reasons.
>
> Perhaps the origin of this thread has been forgotten:
>
> help(alpha) returns:
>
>>>> help(alpha)
> Help on alpha_gen in module scipy.stats.distributions object:
>
> class alpha_gen(rv_continuous)
> ?|? ## Alpha distribution
> :
> :
>
> help(alpha_gen) returns:
>
>>>> help(alpha_gen)
> Traceback (most recent call last):
> ? File "<stdin>", line 1, in <module>
> NameError: name 'alpha_gen' is not defined

do you have alpha_gen in your namespace?
>>> from scipy import stats
>>> help(stats.distributions.alpha_gen)

>
> But (in the Wiki) scipy.stats.distributions.alpha is "full," whereas
> scipy.stats.distributions.alpha_gen is empty (but for automatically
> generated content): help and the doc Wiki appear to exhibit the "transpose"
> of one another - I don't know "which one" is "broken" in this situation, but
> obviously something is.

Most _gen don't have docstrings in the source, but are fully
automatically generated docs
An example for the new template based docstring is
http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/

I'd rather not have wholesale editing of distribution docstrings,
because it is too much to maintain, until we have established that any
new pattern really works. The recipe how distributions work, can be
explained generically without repeating variations on it in 90
different ways.

The pdf, cdf, ... formulas are attached to the scipy.stats tutorial,
based on the original documentation by Travis.

Josef


>
> At what level is help broken: the scipy level or the Python level?? If help
> is simply an alias for print .__doc__, why precisely is this happening?? Is
> this an undiagnosed breakage (in the sense that only the symptom(s), but
> neither the cause(s) nor the cure(s) are known)?
>
> Looking back on this thread, since <X> is the thing users are intended to
> use, it sounds like the docstring _should_ be associated with <X>, not
> <X>_gen, so I guess the Wiki is showing the docstring in the "right" place,
> but why does help associate the docstring with <X>_gen?? And if the
> docstring for <X> is consequently important, is the docstring for <X>_gen
> Unimportant (since its object "should" never be used explicitly)?? If its
> docstring is also important, please explain why.
>
> Thanks.
>
> DG
>
>>
>> If you want to mark them
>> Unimportant just as a workaround, that's fine. But if you are keeping
>> track of items to work on this summer, these are important things to
>> do. You will just have to do it manually.
>>
>> --
>> Robert Kern
>>
>> "I have come to believe that the whole world is an enigma, a harmless
>> enigma that is made terrible by our own mad attempt to interpret it as
>> though it had an underlying truth."
>> ?-- Umberto Eco
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From d.l.goldsmith at gmail.com  Tue May 25 16:26:34 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 25 May 2010 13:26:34 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTinmMfGWkCLgryszgcY-XMnELzRsupc0405LZjWO@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTilL6H84TikVrKA3Y7vU8nfCeYx6aueG_IqVAgQG@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
	<AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
	<AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>
	<AANLkTinmMfGWkCLgryszgcY-XMnELzRsupc0405LZjWO@mail.gmail.com>
Message-ID: <AANLkTim91aBKt-LPAaUhiL4AnzHnpc3lOokcmIsktfZ3@mail.gmail.com>

On Tue, May 25, 2010 at 1:08 PM, <josef.pktd at gmail.com> wrote:

> On Tue, May 25, 2010 at 3:52 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > On Tue, May 25, 2010 at 11:04 AM, Robert Kern <robert.kern at gmail.com>
> wrote:
> >>
> >> On Tue, May 25, 2010 at 12:47, David Goldsmith <d.l.goldsmith at gmail.com
> >
> >> wrote:
> >> > On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers
> >> > <ralf.gommers at googlemail.com>
> >> > wrote:
> >>
> >> >>>  Plus they're not really unimportant.
> >> >>>
> >> >>> Why not?  They're not returned by Python's help system.  (See
> earlier
> >> >>> this same thread.)
> >> >>
> >> >> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken
> >> >> imho.
> >> >
> >> > Care to elaborate? ("Where I come from" help is the proper idiom -
> I've
> >> > never heard of anyone using, nor being told to use, print .__doc__;
> your
> >> > "ho" - that help is broken - strikes me as pretty strange).
> >>
> >> help() is broken in this case because it does not display the .__doc__
> >> attribute that is present. Yes, help() is idiomatic. That doesn't mean
> >> its behavior in this case is not broken. Nor does it mean that the
> >> text in the .__doc__ attributes are Unimportant for the docstring
> >> editing workflow. They just happen to be unavailable to the web
> >> docstring editor for technical reasons.
> >
> > Perhaps the origin of this thread has been forgotten:
> >
> > help(alpha) returns:
> >
> >>>> help(alpha)
> > Help on alpha_gen in module scipy.stats.distributions object:
> >
> > class alpha_gen(rv_continuous)
> >  |  ## Alpha distribution
> > :
> > :
> >
> > help(alpha_gen) returns:
> >
> >>>> help(alpha_gen)
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > NameError: name 'alpha_gen' is not defined
>
> do you have alpha_gen in your namespace?
> >>> from scipy import stats
> >>> help(stats.distributions.alpha_gen)
>
> >
> > But (in the Wiki) scipy.stats.distributions.alpha is "full," whereas
> > scipy.stats.distributions.alpha_gen is empty (but for automatically
> > generated content): help and the doc Wiki appear to exhibit the
> "transpose"
> > of one another - I don't know "which one" is "broken" in this situation,
> but
> > obviously something is.
>
> Most _gen don't have docstrings in the source, but are fully
> automatically generated docs
> An example for the new template based docstring is
> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
>
> I'd rather not have wholesale editing of distribution docstrings,
>

So basically, "hands off" scipy.stats.distributions?  All of scipy.stats?
Would you like me to go through and mark everything as unimportant (I don't
think you can rely on an email thread - be it this one or a new one - as an
adequate safeguard)?  At the end of this road, is
help(scipy.stats[.*[.*[.*]]]) going to behave the same as
help(scipy.<X>[.*[.*[.*]]]), <X> != stats?

DG


> because it is too much to maintain, until we have established that any
> new pattern really works. The recipe how distributions work, can be
> explained generically without repeating variations on it in 90
> different ways.
>
> The pdf, cdf, ... formulas are attached to the scipy.stats tutorial,
> based on the original documentation by Travis.
>
> Josef
>
>
> >
> > At what level is help broken: the scipy level or the Python level?  If
> help
> > is simply an alias for print .__doc__, why precisely is this happening?
> Is
> > this an undiagnosed breakage (in the sense that only the symptom(s), but
> > neither the cause(s) nor the cure(s) are known)?
> >
> > Looking back on this thread, since <X> is the thing users are intended to
> > use, it sounds like the docstring _should_ be associated with <X>, not
> > <X>_gen, so I guess the Wiki is showing the docstring in the "right"
> place,
> > but why does help associate the docstring with <X>_gen?  And if the
> > docstring for <X> is consequently important, is the docstring for <X>_gen
> > Unimportant (since its object "should" never be used explicitly)?  If its
> > docstring is also important, please explain why.
> >
> > Thanks.
> >
> > DG
> >
> >>
> >> If you want to mark them
> >> Unimportant just as a workaround, that's fine. But if you are keeping
> >> track of items to work on this summer, these are important things to
> >> do. You will just have to do it manually.
> >>
> >> --
> >> Robert Kern
> >>
> >> "I have come to believe that the whole world is an enigma, a harmless
> >> enigma that is made terrible by our own mad attempt to interpret it as
> >> though it had an underlying truth."
> >>  -- Umberto Eco
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> uncertainty
> > set is non-empty, even if that set has measure zero.
> >
> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> her
> > lies, prevents mankind from committing a general suicide.  (As
> interpreted
> > by Robert Graves)
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/41fc0137/attachment.html>

From josef.pktd at gmail.com  Tue May 25 16:53:03 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Tue, 25 May 2010 16:53:03 -0400
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTim91aBKt-LPAaUhiL4AnzHnpc3lOokcmIsktfZ3@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTimA2Z5PPIBLbrxVjXtUbH3CdihdzaHsuCQqbfhA@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
	<AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
	<AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>
	<AANLkTinmMfGWkCLgryszgcY-XMnELzRsupc0405LZjWO@mail.gmail.com>
	<AANLkTim91aBKt-LPAaUhiL4AnzHnpc3lOokcmIsktfZ3@mail.gmail.com>
Message-ID: <AANLkTiniskfrBwhIKWshT3bcng9a-C8Ub050XGmfBIr-@mail.gmail.com>

On Tue, May 25, 2010 at 4:26 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Tue, May 25, 2010 at 1:08 PM, <josef.pktd at gmail.com> wrote:
>>
>> On Tue, May 25, 2010 at 3:52 PM, David Goldsmith
>> <d.l.goldsmith at gmail.com> wrote:
>> > On Tue, May 25, 2010 at 11:04 AM, Robert Kern <robert.kern at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, May 25, 2010 at 12:47, David Goldsmith
>> >> <d.l.goldsmith at gmail.com>
>> >> wrote:
>> >> > On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers
>> >> > <ralf.gommers at googlemail.com>
>> >> > wrote:
>> >>
>> >> >>> ?Plus they're not really unimportant.
>> >> >>>
>> >> >>> Why not?? They're not returned by Python's help system.? (See
>> >> >>> earlier
>> >> >>> this same thread.)
>> >> >>
>> >> >> Compare "help(alpha)" with "print alpha.__doc__" - help() is broken
>> >> >> imho.
>> >> >
>> >> > Care to elaborate? ("Where I come from" help is the proper idiom -
>> >> > I've
>> >> > never heard of anyone using, nor being told to use, print .__doc__;
>> >> > your
>> >> > "ho" - that help is broken - strikes me as pretty strange).
>> >>
>> >> help() is broken in this case because it does not display the .__doc__
>> >> attribute that is present. Yes, help() is idiomatic. That doesn't mean
>> >> its behavior in this case is not broken. Nor does it mean that the
>> >> text in the .__doc__ attributes are Unimportant for the docstring
>> >> editing workflow. They just happen to be unavailable to the web
>> >> docstring editor for technical reasons.
>> >
>> > Perhaps the origin of this thread has been forgotten:
>> >
>> > help(alpha) returns:
>> >
>> >>>> help(alpha)
>> > Help on alpha_gen in module scipy.stats.distributions object:
>> >
>> > class alpha_gen(rv_continuous)
>> > ?|? ## Alpha distribution
>> > :
>> > :
>> >
>> > help(alpha_gen) returns:
>> >
>> >>>> help(alpha_gen)
>> > Traceback (most recent call last):
>> > ? File "<stdin>", line 1, in <module>
>> > NameError: name 'alpha_gen' is not defined
>>
>> do you have alpha_gen in your namespace?
>> >>> from scipy import stats
>> >>> help(stats.distributions.alpha_gen)
>>
>> >
>> > But (in the Wiki) scipy.stats.distributions.alpha is "full," whereas
>> > scipy.stats.distributions.alpha_gen is empty (but for automatically
>> > generated content): help and the doc Wiki appear to exhibit the
>> > "transpose"
>> > of one another - I don't know "which one" is "broken" in this situation,
>> > but
>> > obviously something is.
>>
>> Most _gen don't have docstrings in the source, but are fully
>> automatically generated docs
>> An example for the new template based docstring is
>> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
>>
>> I'd rather not have wholesale editing of distribution docstrings,
>
> So basically, "hands off" scipy.stats.distributions?? All of scipy.stats?
> Would you like me to go through and mark everything as unimportant (I don't
> think you can rely on an email thread - be it this one or a new one - as an
> adequate safeguard)?? At the end of this road, is
> help(scipy.stats[.*[.*[.*]]]) going to behave the same as
> help(scipy.<X>[.*[.*[.*]]]), <X> != stats?

this is only for the distributions, I just worry about reviewing 90
cut and paste docstrings.
The instances of the distributions should never be edited, and I hope
eventually we can block this. I would consider the distribution
classes  as very low priority until the dust settles. So as
preliminary measure all distributions instances and classes (except
rv_continuous and rv_discrete) could be marked as unimportant (that's
roughly 180 docstrings in the editor).

The descriptions of the distributions in the tutorial could be
reorganized, e.g. broken up into smaller pieces, as we discussed
before on the mailing lists. But I would consider this also lower
priority, compared to the main documentation in scipy.

Scipy.stats, outside of the distributions, can be treated like any
other scipy sub-package and I appreciate any contribution in improving
those docstrings. I'm pretty slow in working my way through those.

Thanks,

Josef




>
> DG
>
>>
>> because it is too much to maintain, until we have established that any
>> new pattern really works. The recipe how distributions work, can be
>> explained generically without repeating variations on it in 90
>> different ways.
>>
>> The pdf, cdf, ... formulas are attached to the scipy.stats tutorial,
>> based on the original documentation by Travis.
>>
>> Josef
>>
>>
>> >
>> > At what level is help broken: the scipy level or the Python level?? If
>> > help
>> > is simply an alias for print .__doc__, why precisely is this happening?
>> > Is
>> > this an undiagnosed breakage (in the sense that only the symptom(s), but
>> > neither the cause(s) nor the cure(s) are known)?
>> >
>> > Looking back on this thread, since <X> is the thing users are intended
>> > to
>> > use, it sounds like the docstring _should_ be associated with <X>, not
>> > <X>_gen, so I guess the Wiki is showing the docstring in the "right"
>> > place,
>> > but why does help associate the docstring with <X>_gen?? And if the
>> > docstring for <X> is consequently important, is the docstring for
>> > <X>_gen
>> > Unimportant (since its object "should" never be used explicitly)?? If
>> > its
>> > docstring is also important, please explain why.
>> >
>> > Thanks.
>> >
>> > DG
>> >
>> >>
>> >> If you want to mark them
>> >> Unimportant just as a workaround, that's fine. But if you are keeping
>> >> track of items to work on this summer, these are important things to
>> >> do. You will just have to do it manually.
>> >>
>> >> --
>> >> Robert Kern
>> >>
>> >> "I have come to believe that the whole world is an enigma, a harmless
>> >> enigma that is made terrible by our own mad attempt to interpret it as
>> >> though it had an underlying truth."
>> >> ?-- Umberto Eco
>> >> _______________________________________________
>> >> SciPy-Dev mailing list
>> >> SciPy-Dev at scipy.org
>> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> >
>> > --
>> > Mathematician: noun, someone who disavows certainty when their
>> > uncertainty
>> > set is non-empty, even if that set has measure zero.
>> >
>> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
>> > her
>> > lies, prevents mankind from committing a general suicide. ?(As
>> > interpreted
>> > by Robert Graves)
>> >
>> > _______________________________________________
>> > SciPy-Dev mailing list
>> > SciPy-Dev at scipy.org
>> > http://mail.scipy.org/mailman/listinfo/scipy-dev
>> >
>> >
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From d.l.goldsmith at gmail.com  Tue May 25 17:03:10 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 25 May 2010 14:03:10 -0700
Subject: [SciPy-Dev] SciPy Doc "low hanging fruit"
Message-ID: <AANLkTilX4Fvun0dOYo1ZoEwIxagdZPsubvnMjR8fbJ_6@mail.gmail.com>

Hi!  A few days ago I referenced a document I've been preparing roughly
"triaging" the SciPy docstrings; well, I'm done - if you care to view it,
it's here<http://spreadsheets.google.com/ccc?key=0AvCyyT1vWOKJdG5ST2NESTVQWHlFeWMwSmZXd241eFE&hl=en>.
Key: "Empty" = Wiki sees auto-generated content only; "Unsubstantial" >
Empty, but possessing not more than the brief summary, Parameters, and
sometimes Returns, Extended Summary, and perhaps one other, typically
scanty, section; "Substantial" = a lot of content, but flawed in some
fundamental way (e.g., missing an important section, not Standards
compliant); "Ready for Review?" = looks like it might be ready for review,
but I didn't "study" any single docstring, thus the ?; obviously, all but
the first are (perhaps highly) subjective.  Bottom line: docstrings scanned:
2265 (2450 actually, the difference being docstrings for obsolete objects,
which I've already changed to Unimportant status) Empty: 35%, Unsubstantial:
44%, Substantial: 18.5%, Ready for Review?: 2.4% (0.1% rounding error).

So why did I title this email "low hanging fruit"?  Much of both the
Unsubstantial and Substantial content was non-compliant, Standards-wise, and
a simple, easy improvement can be achieved simply by finding these and
making what's already there compliant, and adding correctly ordered headings
for missing (but needed, or likely to be needed) sections.  Low hanging
fruit...

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/ebad536d/attachment.html>

From d.l.goldsmith at gmail.com  Tue May 25 17:39:01 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Tue, 25 May 2010 14:39:01 -0700
Subject: [SciPy-Dev] Design of scipy.stats
In-Reply-To: <AANLkTiniskfrBwhIKWshT3bcng9a-C8Ub050XGmfBIr-@mail.gmail.com>
References: <AANLkTil1plGNTexY3q9zpz-RIRQff3QMVc8qsUKV7JxJ@mail.gmail.com>
	<AANLkTinvrDpP44hKChQzG2N67Iqd0eci3Sgh5BkhPLrv@mail.gmail.com>
	<AANLkTimYTk8AEf5uEyzN5r4hn-aaadqy5M2RdJ_0oiO7@mail.gmail.com>
	<AANLkTin9wLmYEQsNYSEQRC5aXLQ5OEAzqBkKv3910GkB@mail.gmail.com>
	<AANLkTikWfSJlDvhBUVaG2Qf0Ko4TZ5xlULKCiz6rtI9I@mail.gmail.com>
	<AANLkTimCNGGTQSq1o8sWLNgqKrMWVUvYaGkmgNMd3dDq@mail.gmail.com>
	<AANLkTin09L1cadZx8AYmaGbEziD2HzI4LX7kFZhnxHyw@mail.gmail.com>
	<AANLkTinmMfGWkCLgryszgcY-XMnELzRsupc0405LZjWO@mail.gmail.com>
	<AANLkTim91aBKt-LPAaUhiL4AnzHnpc3lOokcmIsktfZ3@mail.gmail.com>
	<AANLkTiniskfrBwhIKWshT3bcng9a-C8Ub050XGmfBIr-@mail.gmail.com>
Message-ID: <AANLkTilmOo6hHgbjqg4HBiQqg3ZrrfGtkLn3iE6sxTCD@mail.gmail.com>

On Tue, May 25, 2010 at 1:53 PM, <josef.pktd at gmail.com> wrote:

> On Tue, May 25, 2010 at 4:26 PM, David Goldsmith
> <d.l.goldsmith at gmail.com> wrote:
> > On Tue, May 25, 2010 at 1:08 PM, <josef.pktd at gmail.com> wrote:
> >>
> >> On Tue, May 25, 2010 at 3:52 PM, David Goldsmith
> >> <d.l.goldsmith at gmail.com> wrote:
> >> > On Tue, May 25, 2010 at 11:04 AM, Robert Kern <robert.kern at gmail.com>
> >> > wrote:
> >> >>
> >> >> On Tue, May 25, 2010 at 12:47, David Goldsmith
> >> >> <d.l.goldsmith at gmail.com>
> >> >> wrote:
> >> >> > On Tue, May 25, 2010 at 8:54 AM, Ralf Gommers
> >> >> > <ralf.gommers at googlemail.com>
> >> >> > wrote:
> >> >>
> >> >> >>>  Plus they're not really unimportant.
> >> >> >>>
> >> >> >>> Why not?  They're not returned by Python's help system.  (See
> >> >> >>> earlier
> >> >> >>> this same thread.)
> >> >> >>
> >> >> >> Compare "help(alpha)" with "print alpha.__doc__" - help() is
> broken
> >> >> >> imho.
> >> >> >
> >> >> > Care to elaborate? ("Where I come from" help is the proper idiom -
> >> >> > I've
> >> >> > never heard of anyone using, nor being told to use, print .__doc__;
> >> >> > your
> >> >> > "ho" - that help is broken - strikes me as pretty strange).
> >> >>
> >> >> help() is broken in this case because it does not display the
> .__doc__
> >> >> attribute that is present. Yes, help() is idiomatic. That doesn't
> mean
> >> >> its behavior in this case is not broken. Nor does it mean that the
> >> >> text in the .__doc__ attributes are Unimportant for the docstring
> >> >> editing workflow. They just happen to be unavailable to the web
> >> >> docstring editor for technical reasons.
> >> >
> >> > Perhaps the origin of this thread has been forgotten:
> >> >
> >> > help(alpha) returns:
> >> >
> >> >>>> help(alpha)
> >> > Help on alpha_gen in module scipy.stats.distributions object:
> >> >
> >> > class alpha_gen(rv_continuous)
> >> >  |  ## Alpha distribution
> >> > :
> >> > :
> >> >
> >> > help(alpha_gen) returns:
> >> >
> >> >>>> help(alpha_gen)
> >> > Traceback (most recent call last):
> >> >   File "<stdin>", line 1, in <module>
> >> > NameError: name 'alpha_gen' is not defined
> >>
> >> do you have alpha_gen in your namespace?
> >> >>> from scipy import stats
> >> >>> help(stats.distributions.alpha_gen)
> >>
> >> >
> >> > But (in the Wiki) scipy.stats.distributions.alpha is "full," whereas
> >> > scipy.stats.distributions.alpha_gen is empty (but for automatically
> >> > generated content): help and the doc Wiki appear to exhibit the
> >> > "transpose"
> >> > of one another - I don't know "which one" is "broken" in this
> situation,
> >> > but
> >> > obviously something is.
> >>
> >> Most _gen don't have docstrings in the source, but are fully
> >> automatically generated docs
> >> An example for the new template based docstring is
> >> http://docs.scipy.org/scipy/docs/scipy.stats.distributions.maxwell_gen/
> >>
> >> I'd rather not have wholesale editing of distribution docstrings,
> >
> > So basically, "hands off" scipy.stats.distributions?  All of scipy.stats?
> > Would you like me to go through and mark everything as unimportant (I
> don't
> > think you can rely on an email thread - be it this one or a new one - as
> an
> > adequate safeguard)?  At the end of this road, is
> > help(scipy.stats[.*[.*[.*]]]) going to behave the same as
> > help(scipy.<X>[.*[.*[.*]]]), <X> != stats?
>
> this is only for the distributions, I just worry about reviewing 90
> cut and paste docstrings.
>

I understand your concern, but I think a "natural" extension of "Document a
single concept once<http://docs.scipy.org/numpy/Front%20Page/#document-a-single-concept-once>"
should suffice, i.e., keep the doc of each individual class to the minimum
necessary to comply w/ the Standard and note any peculiarities, and put all
the shared content in the docstring for stats.distributions (with a See also
reference pointing there in each class docstring).


> The instances of the distributions should never be edited,


Good, I'm glad we cleared that up.


> and I hope
> eventually we can block this.


Even better would be to have pydocweb not "see" them at all.


> I would consider the distribution
> classes as very low priority until the dust settles.


What "dust"?  Are these classes "moving targets"?


> So as
> preliminary measure all distributions instances and classes (except
> rv_continuous and rv_discrete) could be marked as unimportant (that's
> roughly 180 docstrings in the editor).
>

Whew, I thought I was going to have to revert all those Unimportants I
bestowed on all the instances; I'm going to defer doing that to the classes
until I hear what this "dust" is.


> The descriptions of the distributions in the tutorial could be
> reorganized, e.g. broken up into smaller pieces, as we discussed
> before on the mailing lists. But I would consider this also lower
> priority, compared to the main documentation in scipy.
>

Agreed: IMHO, as long as there are deficient (but "important") docstrings in
any sub-package, everything else is a second-tier priority.  (Of course, if
all that remains is outside one's comfort zone, then one can proceed to the
second-tier stuff within their comfort zone.)

>
> Scipy.stats, outside of the distributions, can be treated like any
> other scipy sub-package and I appreciate any contribution in improving
> those docstrings. I'm pretty slow in working my way through those.
>

Good to know, thanks!

Sometime within the next couple of days I'll "codify" the results of this
thread in the Wiki's "Q + A" section.

Thanks for your patience everyone - I (for one) feel satisfied w/ where
we've arrived at. :-)

DG


> Thanks,
>
> Josef
>
>
>
>
> >
> > DG
> >
> >>
> >> because it is too much to maintain, until we have established that any
> >> new pattern really works. The recipe how distributions work, can be
> >> explained generically without repeating variations on it in 90
> >> different ways.
> >>
> >> The pdf, cdf, ... formulas are attached to the scipy.stats tutorial,
> >> based on the original documentation by Travis.
> >>
> >> Josef
> >>
> >>
> >> >
> >> > At what level is help broken: the scipy level or the Python level?  If
> >> > help
> >> > is simply an alias for print .__doc__, why precisely is this
> happening?
> >> > Is
> >> > this an undiagnosed breakage (in the sense that only the symptom(s),
> but
> >> > neither the cause(s) nor the cure(s) are known)?
> >> >
> >> > Looking back on this thread, since <X> is the thing users are intended
> >> > to
> >> > use, it sounds like the docstring _should_ be associated with <X>, not
> >> > <X>_gen, so I guess the Wiki is showing the docstring in the "right"
> >> > place,
> >> > but why does help associate the docstring with <X>_gen?  And if the
> >> > docstring for <X> is consequently important, is the docstring for
> >> > <X>_gen
> >> > Unimportant (since its object "should" never be used explicitly)?  If
> >> > its
> >> > docstring is also important, please explain why.
> >> >
> >> > Thanks.
> >> >
> >> > DG
> >> >
> >> >>
> >> >> If you want to mark them
> >> >> Unimportant just as a workaround, that's fine. But if you are keeping
> >> >> track of items to work on this summer, these are important things to
> >> >> do. You will just have to do it manually.
> >> >>
> >> >> --
> >> >> Robert Kern
> >> >>
> >> >> "I have come to believe that the whole world is an enigma, a harmless
> >> >> enigma that is made terrible by our own mad attempt to interpret it
> as
> >> >> though it had an underlying truth."
> >> >>  -- Umberto Eco
> >> >> _______________________________________________
> >> >> SciPy-Dev mailing list
> >> >> SciPy-Dev at scipy.org
> >> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Mathematician: noun, someone who disavows certainty when their
> >> > uncertainty
> >> > set is non-empty, even if that set has measure zero.
> >> >
> >> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> >> > her
> >> > lies, prevents mankind from committing a general suicide.  (As
> >> > interpreted
> >> > by Robert Graves)
> >> >
> >> > _______________________________________________
> >> > SciPy-Dev mailing list
> >> > SciPy-Dev at scipy.org
> >> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >> >
> >> >
> >> _______________________________________________
> >> SciPy-Dev mailing list
> >> SciPy-Dev at scipy.org
> >> http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> >
> > --
> > Mathematician: noun, someone who disavows certainty when their
> uncertainty
> > set is non-empty, even if that set has measure zero.
> >
> > Hope: noun, that delusive spirit which escaped Pandora's jar and, with
> her
> > lies, prevents mankind from committing a general suicide.  (As
> interpreted
> > by Robert Graves)
> >
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
> >
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100525/12f411d1/attachment.html>

From ralf.gommers at googlemail.com  Wed May 26 11:03:20 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Wed, 26 May 2010 23:03:20 +0800
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
Message-ID: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>

There are a number of deprecations that explicitly mention "remove after
0.7", see below. There are many more that don't mention either when the
deprecation started or when the feature/function/whatever is removed (would
be handy for future deprecations...). If you feel responsible for a certain
part of scipy, can you please check that part for deprecations for 0.8.0?

Thanks,
Ralf


./scipy/linalg/decomp_qr.py:
   75 -         warn("qr econ argument will be removed after scipy 0.7. "
   76 -              "The economy transform will then be available through "
   77 :              "the mode='economic' argument.", DeprecationWarning)

./scipy/sparse/base.py:
  590 -     def save(self, file_name, format = '%d %d %f\n'):
  591 :         #deprecated on Dec 14 2007
  592 +         #remove after 0.7 release
  593 :         warn('save() is deprecated, consider using mmwrite() or
savemat()' \

./scipy/sparse/csc.py:
  100 -             yield csr[r,:]
  101 -
  102 :     @np.deprecate
  103 +     def rowcol(self, ind):
  104 +         #TODO remove after 0.7
./scipy/sparse/csr.py:
   95 -         return csc_matrix((self.data,self.indices,self.indptr),
shape=(N,M), copy=copy)
   96 -
   97 :     @np.deprecate
   98 +     def rowcol(self, ind):
   99 +         #TODO remove after 0.7
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100526/9cafd476/attachment.html>

From chanley at stsci.edu  Wed May 26 12:19:51 2010
From: chanley at stsci.edu (Christopher Hanley)
Date: Wed, 26 May 2010 12:19:51 -0400
Subject: [SciPy-Dev] numpy and the Google App Engine
Message-ID: <AANLkTimze0vMzLJOtqvI_227CgIBAKysU0yzbtV7Fvr4@mail.gmail.com>

Greetings,

Google provides a product called App Engine.  The description from
their site follows,

"Google App Engine enables you to build and host web apps on the same
systems that power Google applications.
App Engine offers fast development and deployment; simple
administration, with no need to worry about hardware,
patches or backups; and effortless scalability. "

You can deploy applications written in either Python or JAVA.  There
are free and paid versions of the service.

The Google App Engine would appear to be a powerful source of CPU
cycles for scientific computing.  Unfortunately this is currently not
the case because numpy is not one of the supported libraries.  The
Python App Engine allows only the installation of user supplied pure
Python code.

I have recently returned from attending the Google I/O conference in
San Francisco.  While there I inquired into the possibility of getting
numpy added.  The basic response was that there doesn't appear to be
much interest from the community given the amount of work it would
take to vet and add numpy.

I would like to ask your help in changing this perception.

The quickest and easiest thing you can do would be to add your "me
too" to this feature request (item #190) on the support site:

http://code.google.com/p/googleappengine/issues/detail?id=190

If this issue is important to you could also consider raising this
issue in the related Google Group:

http://groups.google.com/group/google-appengine

Letting Google know how you will use numpy would be helpful.  If you
or your institution would be willing to pay for service if you could
deploy cloud applications that required numpy would be helpful to let
them know as well.

Finally, if you run into any App Engine developers (Guido included)
let them know that you would like to see numpy added.

Thank you for your time and consideration.

Chris


-- 
Christopher Hanley
Senior Systems Software Engineer
Space Telescope Science Institute
3700 San Martin Drive
Baltimore MD, 21218
(410) 338-4338


From robert.kern at gmail.com  Wed May 26 12:54:17 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 26 May 2010 12:54:17 -0400
Subject: [SciPy-Dev] numpy and the Google App Engine
In-Reply-To: <AANLkTimze0vMzLJOtqvI_227CgIBAKysU0yzbtV7Fvr4@mail.gmail.com>
References: <AANLkTimze0vMzLJOtqvI_227CgIBAKysU0yzbtV7Fvr4@mail.gmail.com>
Message-ID: <AANLkTilQJYMGB05bf1IjiuXOaFemksY0Q7g1e0aJy8ft@mail.gmail.com>

On Wed, May 26, 2010 at 12:19, Christopher Hanley <chanley at stsci.edu> wrote:
> Greetings,
>
> Google provides a product called App Engine. ?The description from
> their site follows,
>
> "Google App Engine enables you to build and host web apps on the same
> systems that power Google applications.
> App Engine offers fast development and deployment; simple
> administration, with no need to worry about hardware,
> patches or backups; and effortless scalability. "
>
> You can deploy applications written in either Python or JAVA. ?There
> are free and paid versions of the service.
>
> The Google App Engine would appear to be a powerful source of CPU
> cycles for scientific computing.

Not really. It is not intended for such purposes. It is intended for
the easy deployment and horizontal scaling of web applications. Each
individual request is very short; it is limited to 10 seconds of CPU
time. While numpy would be useful for scientific web applications (not
least because it would help you keep to that 10 second limit when
doing things like simple image processing or summary statistics or
whatever), it is not a source of CPU cycles. Services like Amazon EC2
or Rackspace Cloud are much closer to what you want. PiCloud provides
an even nicer interface for you:

  http://www.picloud.com/

Disclosure: Enthought partners with PiCloud to provide most EPD
libraries. I can't say I'm disinterested in promoting it, but it *is*
a really powerful product that *does* provide CPU cycles for
scientific computing with an interface much more suited to it than
GAE.

>?Unfortunately this is currently not
> the case because numpy is not one of the supported libraries. ?The
> Python App Engine allows only the installation of user supplied pure
> Python code.
>
> I have recently returned from attending the Google I/O conference in
> San Francisco. ?While there I inquired into the possibility of getting
> numpy added. ?The basic response was that there doesn't appear to be
> much interest from the community given the amount of work it would
> take to vet and add numpy.
>
> I would like to ask your help in changing this perception.
>
> The quickest and easiest thing you can do would be to add your "me
> too" to this feature request (item #190) on the support site:
>
> http://code.google.com/p/googleappengine/issues/detail?id=190

My understanding is that they hate "me too" comments. They ask that
you star the issue instead.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Wed May 26 14:25:58 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 26 May 2010 11:25:58 -0700
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before 0.8.0
Message-ID: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>

Hi Ralf,

On Wed, May 26, 2010 at 8:03 AM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> There are a number of deprecations that explicitly mention "remove after
> 0.7", see below. There are many more that don't mention either when the
> deprecation started or when the feature/function/whatever is removed (would
> be handy for future deprecations...). If you feel responsible for a certain
> part of scipy, can you please check that part for deprecations for 0.8.0?

Thanks very much for taking care of this, sorry for the relative silence...

struct_as_record change
====================

For scipy.io.matlab, I propose one big change to the default behavior
of the readers:

scipy.io.loadmat should _default_ to struct_as_record = True

There's been a warning about this since 0.7.0 and in SVN from November
2008. However - it is a big change.   Any comments?

Others
======

There's a FutureWarning for the default on writing 1D arrays.  At the
moment the default is that 1D arrays written to matlab 4 files are row
vectors in matlab, but they are column vectors for matlab 5 files.
There has been a warning about this from 0.7.1.   I propose to leave
this change until the next version.

There's a FutureWarning for:

scipy.io.loadmat('somefile') # when looking for somefile.mat

I propose to upgrade to a DeprecationWarning

There are DeprecationWarnings for:

scipy.io.loadmat('somefile.mat', basename='something')
scipy.io.savemat('somefile.mat', a_3D_array, format='4') # currently
silently saves to 2D matrix

I propose to upgrade to an Exception in both cases.

Any comments gratefully received...

Matthew


From warren.weckesser at enthought.com  Wed May 26 14:31:33 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 26 May 2010 13:31:33 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
Message-ID: <4BFD6905.9010803@enthought.com>

Ralf Gommers wrote:
> There are a number of deprecations that explicitly mention "remove 
> after 0.7", see below. There are many more that don't mention either 
> when the deprecation started or when the feature/function/whatever is 
> removed (would be handy for future deprecations...). If you feel 
> responsible for a certain part of scipy, can you please check that 
> part for deprecations for 0.8.0?
>
> Thanks,
> Ralf
>
>
> ./scipy/linalg/decomp_qr.py:
>    75 -         warn("qr econ argument will be removed after scipy 0.7. "
>    76 -              "The economy transform will then be available 
> through "
>    77 :              "the mode='economic' argument.", DeprecationWarning)

There is a ticket related to this issue.  I'd look it up and give the 
link, but I haven't been able to get to scipy.org for a few hours.

Warren



>
> ./scipy/sparse/base.py:
>   590 -     def save(self, file_name, format = '%d %d %f\n'):
>   591 :         #deprecated on Dec 14 2007
>   592 +         #remove after 0.7 release
>   593 :         warn('save() is deprecated, consider using mmwrite() 
> or savemat()' \
>
> ./scipy/sparse/csc.py:
>   100 -             yield csr[r,:]
>   101 -
>   102 :     @np.deprecate
>   103 +     def rowcol(self, ind):
>   104 +         #TODO remove after 0.7
> ./scipy/sparse/csr.py:
>    95 -         return 
> csc_matrix((self.data,self.indices,self.indptr), shape=(N,M), copy=copy)
>    96 -
>    97 :     @np.deprecate
>    98 +     def rowcol(self, ind):
>    99 +         #TODO remove after 0.7
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From bsouthey at gmail.com  Wed May 26 14:56:15 2010
From: bsouthey at gmail.com (Bruce Southey)
Date: Wed, 26 May 2010 13:56:15 -0500
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
 0.8.0
In-Reply-To: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
Message-ID: <4BFD6ECF.7010800@gmail.com>

On 05/26/2010 01:25 PM, Matthew Brett wrote:
> Hi Ralf,
>
> On Wed, May 26, 2010 at 8:03 AM, Ralf Gommers
> <ralf.gommers at googlemail.com>  wrote:
>    
>> There are a number of deprecations that explicitly mention "remove after
>> 0.7", see below. There are many more that don't mention either when the
>> deprecation started or when the feature/function/whatever is removed (would
>> be handy for future deprecations...). If you feel responsible for a certain
>> part of scipy, can you please check that part for deprecations for 0.8.0?
>>      
> Thanks very much for taking care of this, sorry for the relative silence...
>
> struct_as_record change
> ====================
>
> For scipy.io.matlab, I propose one big change to the default behavior
> of the readers:
>
> scipy.io.loadmat should _default_ to struct_as_record = True
>
> There's been a warning about this since 0.7.0 and in SVN from November
> 2008. However - it is a big change.   Any comments?
>    
Currently this is a open change:
'FutureWarning: Using struct_as_record default value (False) This will 
change to True in future versions'
  FutureWarning: Using oned_as default value ('column') This will change 
to 'row' in future versions'

I do not use this stuff but I think it should be targeted for 0.9 
version or before the 1.0 version.

Also, I think the tests should be silenced from this warning by adding 
the additional arguments to MatFile5Reader. For example,

rdr = MatFile5Reader(stream, struct_as_record = False) # test_mio.py  
line 633

If that is correct, then I can file a patched test_mio.py for most of 
those. There are a couple of other places that I have not determined the 
cause for those warnings.


> Others
> ======
>
> There's a FutureWarning for the default on writing 1D arrays.  At the
> moment the default is that 1D arrays written to matlab 4 files are row
> vectors in matlab, but they are column vectors for matlab 5 files.
> There has been a warning about this from 0.7.1.   I propose to leave
> this change until the next version.
>
> There's a FutureWarning for:
>
> scipy.io.loadmat('somefile') # when looking for somefile.mat
>
> I propose to upgrade to a DeprecationWarning
>
> There are DeprecationWarnings for:
>
> scipy.io.loadmat('somefile.mat', basename='something')
> scipy.io.savemat('somefile.mat', a_3D_array, format='4') # currently
> silently saves to 2D matrix
>
> I propose to upgrade to an Exception in both cases.
>
> Any comments gratefully received...
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>    

Also, from the email list, the depreciation warnings in scipy/stats 
should be for 0.9:
http://mail.scipy.org/pipermail/scipy-dev/2010-April/014105.html
I do not know how you want to implement the actual version for current 
items (for example, just comment the code) and if other functions need 
to get depreciated.

Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100526/8d6557a3/attachment.html>

From matthew.brett at gmail.com  Wed May 26 15:04:01 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 26 May 2010 12:04:01 -0700
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
	0.8.0
In-Reply-To: <4BFD6ECF.7010800@gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
	<4BFD6ECF.7010800@gmail.com>
Message-ID: <AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com>

Hi,

> Currently this is a open change:
> 'FutureWarning: Using struct_as_record default value (False) This will
> change to True in future versions'
> ?FutureWarning: Using oned_as default value ('column') This will change to
> 'row' in future versions'
>
> I do not use this stuff but I think it should be targeted for 0.9 version or
> before the 1.0 version.

We agree then for the second change, can you say why you think we
should wait another major version for the first change?   I can't
think of a way of upgrading the warning, and it's been there for over
a year now.

> Also, I think the tests should be silenced from this warning by adding the
> additional arguments to MatFile5Reader. For example,
>
> rdr = MatFile5Reader(stream, struct_as_record = False) # test_mio.py? line
> 633
>
> If that is correct, then I can file a patched test_mio.py for most of those.
> There are a couple of other places that I have not determined the cause for
> those warnings.

A patch would be good, thanks.

Cheers,

Matthew


From bsouthey at gmail.com  Wed May 26 15:29:25 2010
From: bsouthey at gmail.com (Bruce Southey)
Date: Wed, 26 May 2010 14:29:25 -0500
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
 0.8.0
In-Reply-To: <AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>	<4BFD6ECF.7010800@gmail.com>
	<AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com>
Message-ID: <4BFD7695.7020503@gmail.com>

On 05/26/2010 02:04 PM, Matthew Brett wrote:
> Hi,
>
>    
>> Currently this is a open change:
>> 'FutureWarning: Using struct_as_record default value (False) This will
>> change to True in future versions'
>>   FutureWarning: Using oned_as default value ('column') This will change to
>> 'row' in future versions'
>>
>> I do not use this stuff but I think it should be targeted for 0.9 version or
>> before the 1.0 version.
>>      
> We agree then for the second change, can you say why you think we
> should wait another major version for the first change?   I can't
> think of a way of upgrading the warning, and it's been there for over
> a year now.
>    
Yes, I know about the time period. I know we went over this type of 
thing with histogram function of numpy but scipy is much slower in 
changing and is still in a 'beta' stage. I would check with Robert and 
Jarrod what they think should happen here.

>    
>> Also, I think the tests should be silenced from this warning by adding the
>> additional arguments to MatFile5Reader. For example,
>>
>> rdr = MatFile5Reader(stream, struct_as_record = False) # test_mio.py  line
>> 633
>>
>> If that is correct, then I can file a patched test_mio.py for most of those.
>> There are a couple of other places that I have not determined the cause for
>> those warnings.
>>      
> A patch would be good, thanks.
>
> Cheers,
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>    

Done:
http://projects.scipy.org/scipy/ticket/1179

However, I have not found the source of two? of the warnings involved.

Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100526/79aa72a2/attachment.html>

From warren.weckesser at enthought.com  Wed May 26 15:39:25 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 26 May 2010 14:39:25 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFD6905.9010803@enthought.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD6905.9010803@enthought.com>
Message-ID: <4BFD78ED.7040908@enthought.com>

Warren Weckesser wrote:
> Ralf Gommers wrote:
>   
>> There are a number of deprecations that explicitly mention "remove 
>> after 0.7", see below. There are many more that don't mention either 
>> when the deprecation started or when the feature/function/whatever is 
>> removed (would be handy for future deprecations...). If you feel 
>> responsible for a certain part of scipy, can you please check that 
>> part for deprecations for 0.8.0?
>>
>> Thanks,
>> Ralf
>>
>>
>> ./scipy/linalg/decomp_qr.py:
>>    75 -         warn("qr econ argument will be removed after scipy 0.7. "
>>    76 -              "The economy transform will then be available 
>> through "
>>    77 :              "the mode='economic' argument.", DeprecationWarning)
>>     
>
> There is a ticket related to this issue.  I'd look it up and give the 
> link, but I haven't been able to get to scipy.org for a few hours.
>
>   

Here it is: http://projects.scipy.org/scipy/ticket/243

Warren

> Warren
>
>
>
>   
>> ./scipy/sparse/base.py:
>>   590 -     def save(self, file_name, format = '%d %d %f\n'):
>>   591 :         #deprecated on Dec 14 2007
>>   592 +         #remove after 0.7 release
>>   593 :         warn('save() is deprecated, consider using mmwrite() 
>> or savemat()' \
>>
>> ./scipy/sparse/csc.py:
>>   100 -             yield csr[r,:]
>>   101 -
>>   102 :     @np.deprecate
>>   103 +     def rowcol(self, ind):
>>   104 +         #TODO remove after 0.7
>> ./scipy/sparse/csr.py:
>>    95 -         return 
>> csc_matrix((self.data,self.indices,self.indptr), shape=(N,M), copy=copy)
>>    96 -
>>    97 :     @np.deprecate
>>    98 +     def rowcol(self, ind):
>>    99 +         #TODO remove after 0.7
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>   
>>     
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From warren.weckesser at enthought.com  Wed May 26 15:49:44 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 26 May 2010 14:49:44 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
Message-ID: <4BFD7B58.3070906@enthought.com>

Along these lines, I would like to close ticket #1136
(http://projects.scipy.org/scipy/ticket/1136), and, while I'm at
it, clean up some of the cruft in scipy.misc.  I think ppimport.py,
helpmod.py, limits.py and pexec.py can all be removed, but I'd like
to get confirmation from some of the scipy devs that have been around
awhile to confirm.

More comments about these files:

misc/ppimport.py
    My understanding is ppimport.py is obsolete and can be removed
    (More information is in ticket #1136.)
    Moreover, the line "postpone_import = 1" in the file info.py of
    each scipy module can also be removed.

misc/helpmod.py
    I didn't find any code in scipy that uses misc/helpmod.py.  It
    looks like the main function defined here is info().  Currently,
    misc/__init__.py defines an info() function based on numpy's info;
    it doesn't expose anything from helpmod.py.  So I assume
    misc/helpmod.py is obsolete and can be removed.  Any objections?

misc/limits.py
    Jarrod added a deprecation warning to this module in September, 2007.
    Any objections to removing this file now?

misc/pexec.py
    Written by Pearu Peteson in 2003, this module defines the class
    ParallelExec.  It is not exposed in misc/__init__.py, and it is
    not mentioned in any docs.  The only way anyone would know about
    it is if they perused the source code.  In addition to being pretty
    well hidden, I don't think this class fits into the current scope
    of scipy.  Any objections to removing it?



Warren


Ralf Gommers wrote:
> There are a number of deprecations that explicitly mention "remove 
> after 0.7", see below. There are many more that don't mention either 
> when the deprecation started or when the feature/function/whatever is 
> removed (would be handy for future deprecations...). If you feel 
> responsible for a certain part of scipy, can you please check that 
> part for deprecations for 0.8.0?
>
> Thanks,
> Ralf
>
>
> ./scipy/linalg/decomp_qr.py:
>    75 -         warn("qr econ argument will be removed after scipy 0.7. "
>    76 -              "The economy transform will then be available 
> through "
>    77 :              "the mode='economic' argument.", DeprecationWarning)
>
> ./scipy/sparse/base.py:
>   590 -     def save(self, file_name, format = '%d %d %f\n'):
>   591 :         #deprecated on Dec 14 2007
>   592 +         #remove after 0.7 release
>   593 :         warn('save() is deprecated, consider using mmwrite() 
> or savemat()' \
>
> ./scipy/sparse/csc.py:
>   100 -             yield csr[r,:]
>   101 -
>   102 :     @np.deprecate
>   103 +     def rowcol(self, ind):
>   104 +         #TODO remove after 0.7
> ./scipy/sparse/csr.py:
>    95 -         return 
> csc_matrix((self.data,self.indices,self.indptr), shape=(N,M), copy=copy)
>    96 -
>    97 :     @np.deprecate
>    98 +     def rowcol(self, ind):
>    99 +         #TODO remove after 0.7
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From matthew.brett at gmail.com  Wed May 26 16:17:14 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Wed, 26 May 2010 13:17:14 -0700
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
	0.8.0
In-Reply-To: <4BFD7695.7020503@gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
	<4BFD6ECF.7010800@gmail.com>
	<AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com>
	<4BFD7695.7020503@gmail.com>
Message-ID: <AANLkTikHaEufaQRWDlF1I43AZKMplH7GL_j0ObIOH76x@mail.gmail.com>

Hi,

> We agree then for the second change, can you say why you think we
> should wait another major version for the first change?   I can't
> think of a way of upgrading the warning, and it's been there for over
> a year now.
>
> Yes, I know about the time period. I know we went over this type of thing
> with histogram function of numpy but scipy is much slower in changing and is
> still in a 'beta' stage. I would check with Robert and Jarrod what they
> think should happen here.

OK - I will go ahead with the original plan in the next few days
unless I hear arguments against in the meantime.

> Also, I think the tests should be silenced from this warning by adding the
> additional arguments to MatFile5Reader. For example,
>
> rdr = MatFile5Reader(stream, struct_as_record = False) # test_mio.py? line
> 633
>
> If that is correct, then I can file a patched test_mio.py for most of those.
> There are a couple of other places that I have not determined the cause for
> those warnings.

Thanks for the patch - I've applied a version - no warnings during
matlab read / write tests for me now.

Best,

Matthew


From millman at berkeley.edu  Wed May 26 18:16:43 2010
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 26 May 2010 15:16:43 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFD7B58.3070906@enthought.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
Message-ID: <AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>

On Wed, May 26, 2010 at 12:49 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Along these lines, I would like to close ticket #1136
> (http://projects.scipy.org/scipy/ticket/1136), and, while I'm at
> it, clean up some of the cruft in scipy.misc. ?I think ppimport.py,
> helpmod.py, limits.py and pexec.py can all be removed, but I'd like
> to get confirmation from some of the scipy devs that have been around
> awhile to confirm.

+1  The whole misc directory needs to get cleaned up.  This would be a
very good start.  You should certainly at least delete limits.py and
add deprecation warnings to the rest.  But I would just remove
ppimport.py, helpmod.py, and pexec.py at this point; I think it is
unlikely many people know about them, much less use them.

Jarrod


From millman at berkeley.edu  Wed May 26 18:26:03 2010
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 26 May 2010 15:26:03 -0700
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
	0.8.0
In-Reply-To: <4BFD7695.7020503@gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com> 
	<4BFD6ECF.7010800@gmail.com>
	<AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com> 
	<4BFD7695.7020503@gmail.com>
Message-ID: <AANLkTim05JT6_RtFRJ7Cn3VBrzSC2q8U7jxcuPwy7x4r@mail.gmail.com>

On Wed, May 26, 2010 at 12:29 PM, Bruce Southey <bsouthey at gmail.com> wrote:
> We agree then for the second change, can you say why you think we
> should wait another major version for the first change?   I can't
> think of a way of upgrading the warning, and it's been there for over
> a year now.
>
> Yes, I know about the time period. I know we went over this type of thing
> with histogram function of numpy but scipy is much slower in changing and is
> still in a 'beta' stage. I would check with Robert and Jarrod what they
> think should happen here.

Personally, given the slower release cycle and that we haven't reached
a 1.0 release yet, I am much less concerned with having a long
deprecation process with SciPy than I am with NumPy.

So my vote is to go ahead with the change to struct_as_record change now.

Jarrod


From cournape at gmail.com  Wed May 26 18:50:31 2010
From: cournape at gmail.com (David Cournapeau)
Date: Thu, 27 May 2010 07:50:31 +0900
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
Message-ID: <AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>

On Thu, May 27, 2010 at 7:16 AM, Jarrod Millman <millman at berkeley.edu> wrote:
> On Wed, May 26, 2010 at 12:49 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>> Along these lines, I would like to close ticket #1136
>> (http://projects.scipy.org/scipy/ticket/1136), and, while I'm at
>> it, clean up some of the cruft in scipy.misc. ?I think ppimport.py,
>> helpmod.py, limits.py and pexec.py can all be removed, but I'd like
>> to get confirmation from some of the scipy devs that have been around
>> awhile to confirm.
>
> +1 ?The whole misc directory needs to get cleaned up. ?This would be a
> very good start. ?You should certainly at least delete limits.py and
> add deprecation warnings to the rest. ?But I would just remove
> ppimport.py, helpmod.py, and pexec.py at this point; I think it is
> unlikely many people know about them, much less use them.

We have a policy to warn about deprecation in at least one release,
and I think we should stick to it. This code, although maybe not
useful anymore, has little maintenance cost, so we don't need to be in
a hurry I think,

David


From millman at berkeley.edu  Wed May 26 18:56:49 2010
From: millman at berkeley.edu (Jarrod Millman)
Date: Wed, 26 May 2010 15:56:49 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
Message-ID: <AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>

On Wed, May 26, 2010 at 3:50 PM, David Cournapeau <cournape at gmail.com> wrote:
> We have a policy to warn about deprecation in at least one release,
> and I think we should stick to it. This code, although maybe not
> useful anymore, has little maintenance cost, so we don't need to be in
> a hurry I think,

So are you OK then with removing limits and deprecating the others?


From warren.weckesser at enthought.com  Wed May 26 19:11:28 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Wed, 26 May 2010 18:11:28 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
Message-ID: <4BFDAAA0.8010808@enthought.com>

Jarrod Millman wrote:
> On Wed, May 26, 2010 at 3:50 PM, David Cournapeau <cournape at gmail.com> wrote:
>   
>> We have a policy to warn about deprecation in at least one release,
>> and I think we should stick to it. This code, although maybe not
>> useful anymore, has little maintenance cost, so we don't need to be in
>> a hurry I think,
>>     
>
> So are you OK then with removing limits and deprecating the others?
>   

This is fine with me.  Stefan made the point in ticket #1136 that, since 
ppimport is currently broken, and it is pointless for anyone to try to 
fix it now, we might as well just remove it.  But I have no problem with 
deprecating it along with helpmod and pexec in 0.8, and waiting until 
after 0.8 is branched to remove them from the trunk.

Warren

> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From david at silveregg.co.jp  Wed May 26 21:01:01 2010
From: david at silveregg.co.jp (David)
Date: Thu, 27 May 2010 10:01:01 +0900
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
Message-ID: <4BFDC44D.9070008@silveregg.co.jp>

On 05/27/2010 07:56 AM, Jarrod Millman wrote:
> On Wed, May 26, 2010 at 3:50 PM, David Cournapeau<cournape at gmail.com>  wrote:
>> We have a policy to warn about deprecation in at least one release,
>> and I think we should stick to it. This code, although maybe not
>> useful anymore, has little maintenance cost, so we don't need to be in
>> a hurry I think,
>
> So are you OK then with removing limits and deprecating the others?

I think we should never remove anything without one release with 
deprecation as a rule. Given it is python code (and as such as no cost 
as long as you don't use it), I would rather follow the policy in that 
case. Unless there is a reason to actually remove it prompto which I 
missed ?

cheers,

David


From ralf.gommers at googlemail.com  Thu May 27 06:50:10 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Thu, 27 May 2010 18:50:10 +0800
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
	0.8.0
In-Reply-To: <AANLkTikHaEufaQRWDlF1I43AZKMplH7GL_j0ObIOH76x@mail.gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
	<4BFD6ECF.7010800@gmail.com>
	<AANLkTinxWgKMqF_gs6P4MBiDyMygF-VzTAlqMdo_SUY2@mail.gmail.com>
	<4BFD7695.7020503@gmail.com>
	<AANLkTikHaEufaQRWDlF1I43AZKMplH7GL_j0ObIOH76x@mail.gmail.com>
Message-ID: <AANLkTilhj_mhig2_bcl31tU9cUVzhSARrx_2xbX56Dtm@mail.gmail.com>

On Thu, May 27, 2010 at 4:17 AM, Matthew Brett <matthew.brett at gmail.com>wrote:

>
> > Also, I think the tests should be silenced from this warning by adding
> the
> > additional arguments to MatFile5Reader. For example,
> >
> > rdr = MatFile5Reader(stream, struct_as_record = False) # test_mio.py
> line
> > 633
> >
> > If that is correct, then I can file a patched test_mio.py for most of
> those.
> > There are a couple of other places that I have not determined the cause
> for
> > those warnings.
>
> Thanks for the patch - I've applied a version - no warnings during
> matlab read / write tests for me now.
>
> Thanks for cleaning that up, test output is a lot more quiet now. I do have
one new failure though:

======================================================================
FAIL: test_mio_utils.test_squeeze_element(False,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
line 183, in runTest
    self.test(*self.arg)
AssertionError


Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/0baa561f/attachment.html>

From warren.weckesser at enthought.com  Thu May 27 10:18:50 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 09:18:50 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFDC44D.9070008@silveregg.co.jp>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp>
Message-ID: <4BFE7F4A.7010805@enthought.com>

David wrote:
> On 05/27/2010 07:56 AM, Jarrod Millman wrote:
>   
>> On Wed, May 26, 2010 at 3:50 PM, David Cournapeau<cournape at gmail.com>  wrote:
>>     
>>> We have a policy to warn about deprecation in at least one release,
>>> and I think we should stick to it. This code, although maybe not
>>> useful anymore, has little maintenance cost, so we don't need to be in
>>> a hurry I think,
>>>       
>> So are you OK then with removing limits and deprecating the others?
>>     
>
> I think we should never remove anything without one release with 
> deprecation as a rule. Given it is python code (and as such as no cost 
> as long as you don't use it), I would rather follow the policy in that 
> case. Unless there is a reason to actually remove it prompto which I 
> missed ?
>
>   


OK. In r6416, the limits module is removed, and the modules helpmod, 
ppimport and pexec have deprecation warnings.

Warren




From ralf.gommers at googlemail.com  Thu May 27 12:31:15 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 28 May 2010 00:31:15 +0800
Subject: [SciPy-Dev] request review of some test cleaning
Message-ID: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>

Hi, can I ask for a review of this:
http://github.com/rgommers/scipy/tree/cleantests
Should be very quick.

Summary of changes:
linalg: remove warnings about flapack/clapack being empty, and silence
funm/signm tests.
stats: http://projects.scipy.org/scipy/ticket/1147
weave: remove, or change to warnings, some printed messages.

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100528/bde20b4d/attachment.html>

From josef.pktd at gmail.com  Thu May 27 12:45:20 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 12:45:20 -0400
Subject: [SciPy-Dev] request review of some test cleaning
In-Reply-To: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>
References: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>
Message-ID: <AANLkTilBVK_ysBmZ16ygbpsAER7Vq3bBDkrfedLlQ10F@mail.gmail.com>

On Thu, May 27, 2010 at 12:31 PM, Ralf Gommers
<ralf.gommers at googlemail.com> wrote:
> Hi, can I ask for a review of this:
> http://github.com/rgommers/scipy/tree/cleantests
> Should be very quick.
>
> Summary of changes:
> linalg: remove warnings about flapack/clapack being empty, and silence
> funm/signm tests.
> stats: http://projects.scipy.org/scipy/ticket/1147

fine with me, I checked that the warning is in the Notes section of
the docstring

Josef

> weave: remove, or change to warnings, some printed messages.
>
> Thanks,
> Ralf
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From warren.weckesser at enthought.com  Thu May 27 12:52:47 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 11:52:47 -0500
Subject: [SciPy-Dev] request review of some test cleaning
In-Reply-To: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>
References: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>
Message-ID: <4BFEA35F.9000505@enthought.com>

Ralf Gommers wrote:
> Hi, can I ask for a review of this: 
> http://github.com/rgommers/scipy/tree/cleantests
> Should be very quick.
>
> Summary of changes:
> linalg: remove warnings about flapack/clapack being empty, and silence 
> funm/signm tests.

+1.  You probably noticed that those three tests of signm aren't 
finished--they don't actually test anything.

On my "to do" list for scipy.linalg is the issue of the 'disp' argument 
and return values of funm, logm, signm and sqrtm.  It would be nice to 
just get rid of the 'disp' argument.  But that issue will have to wait 
until 0.9.

> stats: http://projects.scipy.org/scipy/ticket/1147

+1

> weave: remove, or change to warnings, some printed messages.

github suddenly got slow, so I haven't looked at these changes.  But in 
principle, removing or replacing print statements gets a +1.

>
> Thanks,
> Ralf
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From stefan at sun.ac.za  Thu May 27 13:21:50 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 27 May 2010 10:21:50 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFE7F4A.7010805@enthought.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
Message-ID: <AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>

On 27 May 2010 07:18, Warren Weckesser <warren.weckesser at enthought.com> wrote:
> OK. In r6416, the limits module is removed, and the modules helpmod,
> ppimport and pexec have deprecation warnings.

Any comment on ppimport, which is currently non-functional?

Regards
St?fan


From stefan at sun.ac.za  Thu May 27 13:37:59 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 27 May 2010 10:37:59 -0700
Subject: [SciPy-Dev] request review of some test cleaning
In-Reply-To: <4BFEA35F.9000505@enthought.com>
References: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com> 
	<4BFEA35F.9000505@enthought.com>
Message-ID: <AANLkTim4gRapO248CWwKMJVRssHx_YBLI4GNnfY96MKj@mail.gmail.com>

On 27 May 2010 09:52, Warren Weckesser <warren.weckesser at enthought.com> wrote:
> On my "to do" list for scipy.linalg is the issue of the 'disp' argument
> and return values of funm, logm, signm and sqrtm. ?It would be nice to
> just get rid of the 'disp' argument. ?But that issue will have to wait
> until 0.9.

I also picked that up while reviewing.  If we leave 'disp' in place
and raise a warning on error (instead of printing), we're not
technically breaking the API.  We can also raise a pending deprecation
warning whenever `disp` is used.

St?fan


From josef.pktd at gmail.com  Thu May 27 13:42:32 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 13:42:32 -0400
Subject: [SciPy-Dev] tests crash
Message-ID: <AANLkTim1eCXNekUpeNh_KhT4obRP--nGYrksTAsVP9Bp@mail.gmail.com>

I just tried current trunk scipy (build against numpy 1.4.0)

build looks fine but scipy.test() crashes

I get an old error
** On entry to DGEEV , parameter number  5 had an illegal value

previously this error wasn't fatal, now python crashes.

verbose shows it is in test_ltisys.TestSS2TF.test_basic(0, 3, 3)

Is this a new known problem?

without test_ltisys.py, I get

Ran 4410 tests in 93.312s
FAILED (KNOWNFAIL=11, SKIP=33, errors=6, failures=2)
<nose.result.TextTestResult run=4410 errors=6 failures=2>

(3 io/matlab errors that I haven't seen before)

It could be my build setup, but I don't have the time to debug it (and
I didn't change it in a long time).

Josef


From d.l.goldsmith at gmail.com  Thu May 27 13:47:08 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Thu, 27 May 2010 10:47:08 -0700
Subject: [SciPy-Dev] Summer Marathon Skypecon tomorrow
Message-ID: <AANLkTimX7YUGtwqLlHnCGO_fD9kkVJqWnjPhA9GvHq0l@mail.gmail.com>

So far, no one has RSVP-ed (positive or negative).  Is this due to:

A) Lack of time;
B) Bad scheduling (i.e., you have time, just not at the time we've chosen);
C) Lack of interest;
D) Lack of issues to discuss (i.e., you have interest, but not in a meeting
without a specific aganda);
E) Bad choice of conference media (i.e., can't/won't do Skype);
F) Just forgot to RSVP;
G) Some of the above;
H) Other/None of the above?

If I haven't heard from anyone, in the positive, by midnight tonight, EDT,
this week's Skypecon is canceled.

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/fa4c5ecf/attachment.html>

From josef.pktd at gmail.com  Thu May 27 14:03:50 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 14:03:50 -0400
Subject: [SciPy-Dev] scipy 0.8 stats
Message-ID: <AANLkTikXonBniTPThd4TJBoy8WTXfvV8ONBuE10xviXs@mail.gmail.com>

1)
How can we depreciate a class and a class instance?

for renaming of a distribution invnorm to invgauss
http://projects.scipy.org/scipy/ticket/1172

2)
two functions clearly return wrong values
pdfapprox returns "strange" (wrong) values, pdf_moments doesn't do any expansion
http://projects.scipy.org/scipy/ticket/173

I would like to remove these two functions until they can be replaced
Is it better to rename them to _pdfapprox , _pdf_moments or comment them out?

I'd like to break the API in this case, because anyone who used them,
didn't get anything correct.
pdf_fromgamma might be ok.

3)
Assuming I have an updated, working scipy, I will change spearman
today or tomorrow
http://projects.scipy.org/scipy/ticket/1100
http://projects.scipy.org/scipy/ticket/822

4)
a faster kendall tau would be nice, if somone or I manages to include this
http://projects.scipy.org/scipy/ticket/999

Josef


From josef.pktd at gmail.com  Thu May 27 14:23:33 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 14:23:33 -0400
Subject: [SciPy-Dev] ltisys test
Message-ID: <AANLkTil16taLX0bDvBbFSYhuyoXppdt1VSQF1IAdBwRN@mail.gmail.com>

class TestSS2TF:
    def tst_matrix_shapes(self, p, q, r):
        ss2tf(np.zeros((p, p)),
              np.zeros((p, q)),
              np.zeros((r, p)),
              np.zeros((r, q)), 0)

    def test_basic(self):
        for p, q, r in [
            (3, 3, 3),
            (0, 3, 3),
            (1, 1, 1)]:
            print p, q, r
            self.tst_matrix_shapes( p, q, r)

TestSS2TF().test_basic()

>tryltisys.py
3 3 3
0 3 3
 ** On entry to DGEEV  parameter number  5 had an illegal value

crashes when p=0,  some system matrices have zero length in one axis.
Is this a good testcase?

Josef


From josef.pktd at gmail.com  Thu May 27 14:32:03 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 14:32:03 -0400
Subject: [SciPy-Dev] io/matlab test errors
Message-ID: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>

does anyone get these?  WindosXP32, numpy 1.4.0, scipy 0.8.0.dev6416

Josef

>nosetests scipy.io

======================================================================
ERROR: Failure: TypeError (Expecting miMATRIX type here, got 3917)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
.py", line 224, in generate
    for test in g():
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
, line 718, in test_func_read
    d = rdr.get_variables()
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
 in get_variables
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
 in read_var_header
TypeError: Expecting miMATRIX type here, got 3917

======================================================================
ERROR: Failure: TypeError (Expecting miMATRIX type here, got 1224736768)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
.py", line 224, in generate
    for test in g():
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
, line 728, in test_mat_dtype
    d = rdr.get_variables()
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
 in get_variables
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
 in read_var_header
TypeError: Expecting miMATRIX type here, got 1224736768

======================================================================
ERROR: Failure: error (Error -3 while decompressing: invalid distance too far ba
ck)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
.py", line 379, in loadTestsFromName
    addr.filename, addr.module)
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
er.py", line 39, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
er.py", line 86, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
cs.py", line 57, in <module>
    ws_vars = read_workspace_vars(fname)
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
cs.py", line 44, in read_workspace_vars
    vars = rdr.get_variables()
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
 in get_variables
  File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 362,
 in read_var_header
error: Error -3 while decompressing: invalid distance too far back

======================================================================
ERROR: test suite for <module 'test_streams' from 'C:\Josef\_progs\Subversion\sc
ipy-trunk_after\trunk\dist\scipy-0.8.0.dev6416.win32\Programs\Python25\Lib\site-
packages\scipy\io\matlab\tests\test_streams.pyc'>
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
py", line 201, in run
    self.tearDown()
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
py", line 323, in tearDown
    self.teardownContext(ancestor)
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
py", line 339, in teardownContext
    try_run(context, names)
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\util.p
y", line 487, in try_run
    return func()
  File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_streams
.py", line 37, in teardown
    os.unlink(fname)
WindowsError: [Error 32] The process cannot access the file because it is being
used by another process: 'c:\\docume~1\\josef\\locals~1\\temp\\tmpcx8egl'

======================================================================
FAIL: test_mio_utils.test_squeeze_element(False,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
y", line 183, in runTest
    self.test(*self.arg)
AssertionError

----------------------------------------------------------------------
Ran 386 tests in 2.328s

FAILED (errors=4, failures=1)


From warren.weckesser at enthought.com  Thu May 27 17:52:51 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 16:52:51 -0500
Subject: [SciPy-Dev] ltisys test
In-Reply-To: <AANLkTil16taLX0bDvBbFSYhuyoXppdt1VSQF1IAdBwRN@mail.gmail.com>
References: <AANLkTil16taLX0bDvBbFSYhuyoXppdt1VSQF1IAdBwRN@mail.gmail.com>
Message-ID: <4BFEE9B3.6080505@enthought.com>

On Mac OSX 10.5, scipy trunk with numpy 1.4.0 (from EPD 6.1), I also get 
the DGEEV error when run the ltisys tests:

$ nosetests test_ltisys.py
.Parameter 5 to routine DGEEV  was incorrect
Mac OS BLAS parameter error in DGEEV , parameter #0, (unavailable), is 0
$


Warren


josef.pktd at gmail.com wrote:
> class TestSS2TF:
>     def tst_matrix_shapes(self, p, q, r):
>         ss2tf(np.zeros((p, p)),
>               np.zeros((p, q)),
>               np.zeros((r, p)),
>               np.zeros((r, q)), 0)
>
>     def test_basic(self):
>         for p, q, r in [
>             (3, 3, 3),
>             (0, 3, 3),
>             (1, 1, 1)]:
>             print p, q, r
>             self.tst_matrix_shapes( p, q, r)
>
> TestSS2TF().test_basic()
>
>   
>> tryltisys.py
>>     
> 3 3 3
> 0 3 3
>  ** On entry to DGEEV  parameter number  5 had an illegal value
>
> crashes when p=0,  some system matrices have zero length in one axis.
> Is this a good testcase?
>
> Josef
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From warren.weckesser at enthought.com  Thu May 27 18:02:25 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 17:02:25 -0500
Subject: [SciPy-Dev] io/matlab test errors
In-Reply-To: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
References: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
Message-ID: <4BFEEBF1.10909@enthought.com>

josef.pktd at gmail.com wrote:
> does anyone get these?  WindosXP32, numpy 1.4.0, scipy 0.8.0.dev6416
>
>   

On Mac OSX 10.5 with scipy r6417 and numpy 1.4.0, I only get the last 
error that you got.  The following is in scipy/io/matlab/tests:

$ nosetests
.......................................................................................................................................................................................F.........................................................
======================================================================
FAIL: test_mio_utils.test_squeeze_element(False,)
----------------------------------------------------------------------
Traceback (most recent call last):
  File 
"/Library/Frameworks/Python.framework/Versions/6.1/lib/python2.6/site-packages/nose/case.py", 
line 183, in runTest
    self.test(*self.arg)
AssertionError

----------------------------------------------------------------------
Ran 241 tests in 0.809s

FAILED (failures=1)
$


Warren


> Josef
>
>   
>> nosetests scipy.io
>>     
>
> ======================================================================
> ERROR: Failure: TypeError (Expecting miMATRIX type here, got 3917)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 224, in generate
>     for test in g():
>   File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
> , line 718, in test_func_read
>     d = rdr.get_variables()
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
>  in get_variables
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
>  in read_var_header
> TypeError: Expecting miMATRIX type here, got 3917
>
> ======================================================================
> ERROR: Failure: TypeError (Expecting miMATRIX type here, got 1224736768)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 224, in generate
>     for test in g():
>   File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
> , line 728, in test_mat_dtype
>     d = rdr.get_variables()
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
>  in get_variables
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
>  in read_var_header
> TypeError: Expecting miMATRIX type here, got 1224736768
>
> ======================================================================
> ERROR: Failure: error (Error -3 while decompressing: invalid distance too far ba
> ck)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 379, in loadTestsFromName
>     addr.filename, addr.module)
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
> er.py", line 39, in importFromPath
>     return self.importFromDir(dir_path, fqname)
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
> er.py", line 86, in importFromDir
>     mod = load_module(part_fqname, fh, filename, desc)
>   File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
> cs.py", line 57, in <module>
>     ws_vars = read_workspace_vars(fname)
>   File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
> cs.py", line 44, in read_workspace_vars
>     vars = rdr.get_variables()
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
>  in get_variables
>   File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 362,
>  in read_var_header
> error: Error -3 while decompressing: invalid distance too far back
>
> ======================================================================
> ERROR: test suite for <module 'test_streams' from 'C:\Josef\_progs\Subversion\sc
> ipy-trunk_after\trunk\dist\scipy-0.8.0.dev6416.win32\Programs\Python25\Lib\site-
> packages\scipy\io\matlab\tests\test_streams.pyc'>
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 201, in run
>     self.tearDown()
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 323, in tearDown
>     self.teardownContext(ancestor)
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 339, in teardownContext
>     try_run(context, names)
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\util.p
> y", line 487, in try_run
>     return func()
>   File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_streams
> .py", line 37, in teardown
>     os.unlink(fname)
> WindowsError: [Error 32] The process cannot access the file because it is being
> used by another process: 'c:\\docume~1\\josef\\locals~1\\temp\\tmpcx8egl'
>
> ======================================================================
> FAIL: test_mio_utils.test_squeeze_element(False,)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
> y", line 183, in runTest
>     self.test(*self.arg)
> AssertionError
>
> ----------------------------------------------------------------------
> Ran 386 tests in 2.328s
>
> FAILED (errors=4, failures=1)
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From warren.weckesser at enthought.com  Thu May 27 18:14:11 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 17:14:11 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
Message-ID: <4BFEEEB3.9050602@enthought.com>

St?fan van der Walt wrote:
> On 27 May 2010 07:18, Warren Weckesser <warren.weckesser at enthought.com> wrote:
>   
>> OK. In r6416, the limits module is removed, and the modules helpmod,
>> ppimport and pexec have deprecation warnings.
>>     
>
> Any comment on ppimport, which is currently non-functional?
>
>   

I guess there are three options:

1. Fix it and deprecate it.
2. Deprecate it, but don't bother fixing it.
3. Remove it without bothering with a cycle of deprecation.

I'm not planning on fixing it, and I don't think anyone else should, 
either--there are too many other more important things to do than fix a 
module that hasn't worked in who-knows-how-long and is going to be 
removed anyway.  So #1 is out.

My initial preference was for #3, but David C. suggested sticking with 
the deprecation policy, which is fine with me.  I'll just remove it next 
week, after 0.8 is branched, so it will be gone in 0.9.  So, revision 
r6416 assumes #2.

Warren

> Regards
> St?fan
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From cournape at gmail.com  Thu May 27 18:18:23 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 28 May 2010 07:18:23 +0900
Subject: [SciPy-Dev] io/matlab test errors
In-Reply-To: <4BFEEBF1.10909@enthought.com>
References: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
	<4BFEEBF1.10909@enthought.com>
Message-ID: <AANLkTimfS-vS_GKaqrRYqOy1arWZjiHL95QsZHsf11kC@mail.gmail.com>

On Fri, May 28, 2010 at 7:02 AM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> josef.pktd at gmail.com wrote:
>> does anyone get these? ?WindosXP32, numpy 1.4.0, scipy 0.8.0.dev6416
>>
>>
>
> On Mac OSX 10.5 with scipy r6417 and numpy 1.4.0, I only get the last
> error that you got.

Yes, it is a bug (file descriptor/objects are leaking), and windows
make them more apparent because you can't remove or modify a file
already accessed by another process (or by itself in some cases).

cheers,

David


From matthew.brett at gmail.com  Thu May 27 18:20:50 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 15:20:50 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFEEEB3.9050602@enthought.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
Message-ID: <AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>

Hi,

> 1. Fix it and deprecate it.
> 2. Deprecate it, but don't bother fixing it.
> 3. Remove it without bothering with a cycle of deprecation.

> My initial preference was for #3, but David C. suggested sticking with
> the deprecation policy, which is fine with me. ?I'll just remove it next
> week, after 0.8 is branched, so it will be gone in 0.9. ?So, revision
> r6416 assumes #2.

The deprecation would be because someone may have been using it, and
they would be surprised to see it has gone, and that surprise would
seem to them to be a flaw in scipy.  We want to avoid that.

However, if it is broken, then it seems to me that the user will be
more likely to think that the flaw is leaving in code that is broken.
 It's also unlikely that anyone will be surprised to see it go if it
hasn't worked for a long time.

So - if it has not been working for at least one version, and we are
not thinking of fixing it, I vote to remove.   Does that seem
reasonable?

Matthew


From matthew.brett at gmail.com  Thu May 27 18:22:10 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 15:22:10 -0700
Subject: [SciPy-Dev] io/matlab test errors
In-Reply-To: <AANLkTimfS-vS_GKaqrRYqOy1arWZjiHL95QsZHsf11kC@mail.gmail.com>
References: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
	<4BFEEBF1.10909@enthought.com>
	<AANLkTimfS-vS_GKaqrRYqOy1arWZjiHL95QsZHsf11kC@mail.gmail.com>
Message-ID: <AANLkTikW58LOwrPuB0OFYSyYPjOyOaL-_2icRVZHsnq3@mail.gmail.com>

Hi,

On Thu, May 27, 2010 at 3:18 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Fri, May 28, 2010 at 7:02 AM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>> josef.pktd at gmail.com wrote:
>>> does anyone get these? ?WindosXP32, numpy 1.4.0, scipy 0.8.0.dev6416
>>>
>>>
>>
>> On Mac OSX 10.5 with scipy r6417 and numpy 1.4.0, I only get the last
>> error that you got.
>
> Yes, it is a bug (file descriptor/objects are leaking), and windows
> make them more apparent because you can't remove or modify a file
> already accessed by another process (or by itself in some cases).

I'm just honing my windows skills at the moment, I will try and fix today,

Matthew


From josef.pktd at gmail.com  Thu May 27 19:20:56 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 19:20:56 -0400
Subject: [SciPy-Dev] ltisys test
In-Reply-To: <4BFEE9B3.6080505@enthought.com>
References: <AANLkTil16taLX0bDvBbFSYhuyoXppdt1VSQF1IAdBwRN@mail.gmail.com>
	<4BFEE9B3.6080505@enthought.com>
Message-ID: <AANLkTik7hT6mbI3qoFtDFEFevlWrSaH04bwLqbQrQuA8@mail.gmail.com>

On Thu, May 27, 2010 at 5:52 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> On Mac OSX 10.5, scipy trunk with numpy 1.4.0 (from EPD 6.1), I also get
> the DGEEV error when run the ltisys tests:
>
> $ nosetests test_ltisys.py
> .Parameter 5 to routine DGEEV ?was incorrect
> Mac OS BLAS parameter error in DGEEV , parameter #0, (unavailable), is 0
> $

crash in np.poly
>>> np.poly(np.zeros((0,0)))
 ** On entry to DGEEV  parameter number  5 had an illegal value


Warren, I think you could set the 0 to 1 in the ltisys test. that
would make more sense, or not?

Josef


>
>
> Warren
>
>
> josef.pktd at gmail.com wrote:
>> class TestSS2TF:
>> ? ? def tst_matrix_shapes(self, p, q, r):
>> ? ? ? ? ss2tf(np.zeros((p, p)),
>> ? ? ? ? ? ? ? np.zeros((p, q)),
>> ? ? ? ? ? ? ? np.zeros((r, p)),
>> ? ? ? ? ? ? ? np.zeros((r, q)), 0)
>>
>> ? ? def test_basic(self):
>> ? ? ? ? for p, q, r in [
>> ? ? ? ? ? ? (3, 3, 3),
>> ? ? ? ? ? ? (0, 3, 3),
>> ? ? ? ? ? ? (1, 1, 1)]:
>> ? ? ? ? ? ? print p, q, r
>> ? ? ? ? ? ? self.tst_matrix_shapes( p, q, r)
>>
>> TestSS2TF().test_basic()
>>
>>
>>> tryltisys.py
>>>
>> 3 3 3
>> 0 3 3
>> ?** On entry to DGEEV ?parameter number ?5 had an illegal value
>>
>> crashes when p=0, ?some system matrices have zero length in one axis.
>> Is this a good testcase?
>>
>> Josef
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From robert.kern at gmail.com  Thu May 27 19:39:43 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 May 2010 19:39:43 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
Message-ID: <AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>

On Thu, May 27, 2010 at 18:20, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
>> 1. Fix it and deprecate it.
>> 2. Deprecate it, but don't bother fixing it.
>> 3. Remove it without bothering with a cycle of deprecation.
>
>> My initial preference was for #3, but David C. suggested sticking with
>> the deprecation policy, which is fine with me. ?I'll just remove it next
>> week, after 0.8 is branched, so it will be gone in 0.9. ?So, revision
>> r6416 assumes #2.
>
> The deprecation would be because someone may have been using it, and
> they would be surprised to see it has gone, and that surprise would
> seem to them to be a flaw in scipy. ?We want to avoid that.
>
> However, if it is broken, then it seems to me that the user will be
> more likely to think that the flaw is leaving in code that is broken.
> ?It's also unlikely that anyone will be surprised to see it go if it
> hasn't worked for a long time.
>
> So - if it has not been working for at least one version, and we are
> not thinking of fixing it, I vote to remove. ? Does that seem
> reasonable?

I see no reason to break our deprecation rule. If it were actively
causing problems, like complicating the build, then that might be a
reason to break the rule. We shouldn't seek out excuses to break the
rule.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From ralf.gommers at googlemail.com  Thu May 27 20:01:20 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 28 May 2010 08:01:20 +0800
Subject: [SciPy-Dev] Summer Marathon Skypecon tomorrow
In-Reply-To: <AANLkTimX7YUGtwqLlHnCGO_fD9kkVJqWnjPhA9GvHq0l@mail.gmail.com>
References: <AANLkTimX7YUGtwqLlHnCGO_fD9kkVJqWnjPhA9GvHq0l@mail.gmail.com>
Message-ID: <AANLkTilw8_A2H4fDbeTkh3HlFQUff9cRo1WXtP6v9qZ5@mail.gmail.com>

A and D.

Ralf


On Fri, May 28, 2010 at 1:47 AM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> So far, no one has RSVP-ed (positive or negative).  Is this due to:
>
> A) Lack of time;
> B) Bad scheduling (i.e., you have time, just not at the time we've chosen);
> C) Lack of interest;
> D) Lack of issues to discuss (i.e., you have interest, but not in a meeting
> without a specific aganda);
> E) Bad choice of conference media (i.e., can't/won't do Skype);
> F) Just forgot to RSVP;
> G) Some of the above;
> H) Other/None of the above?
>
> If I haven't heard from anyone, in the positive, by midnight tonight, EDT,
> this week's Skypecon is canceled.
>
> DG
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100528/e57563ca/attachment.html>

From ralf.gommers at googlemail.com  Thu May 27 20:15:27 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Fri, 28 May 2010 08:15:27 +0800
Subject: [SciPy-Dev] request review of some test cleaning
In-Reply-To: <AANLkTim4gRapO248CWwKMJVRssHx_YBLI4GNnfY96MKj@mail.gmail.com>
References: <AANLkTinjS4K1kzBPpw7RAzi4tnx03B07jvdZ0CQACW0a@mail.gmail.com>
	<4BFEA35F.9000505@enthought.com>
	<AANLkTim4gRapO248CWwKMJVRssHx_YBLI4GNnfY96MKj@mail.gmail.com>
Message-ID: <AANLkTilSLG0ttAuGNLasJOpBQK63R2RrNwY4hAMGuMAg@mail.gmail.com>

2010/5/28 St?fan van der Walt <stefan at sun.ac.za>

> On 27 May 2010 09:52, Warren Weckesser <warren.weckesser at enthought.com>
> wrote:
> > On my "to do" list for scipy.linalg is the issue of the 'disp' argument
> > and return values of funm, logm, signm and sqrtm.  It would be nice to
> > just get rid of the 'disp' argument.  But that issue will have to wait
> > until 0.9.
>
> I also picked that up while reviewing.  If we leave 'disp' in place
> and raise a warning on error (instead of printing), we're not
> technically breaking the API.  We can also raise a pending deprecation
> warning whenever `disp` is used.
>
> You can also do nothing instead of printing. disp is like full_output, if
you care about the accuracy you should just grab the error as a return value
- printing or warning with an arbitrary criterion is just annoying.

Warren, if you have no time for this now I'll just merge the tests like they
are now on Sunday. Otherwise I'll adapt it.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100528/133885bf/attachment.html>

From matthew.brett at gmail.com  Thu May 27 20:17:28 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 17:17:28 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
Message-ID: <AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>

Hi,

>> However, if it is broken, then it seems to me that the user will be
>> more likely to think that the flaw is leaving in code that is broken.
>> ?It's also unlikely that anyone will be surprised to see it go if it
>> hasn't worked for a long time.
>>
>> So - if it has not been working for at least one version, and we are
>> not thinking of fixing it, I vote to remove. ? Does that seem
>> reasonable?
>
> I see no reason to break our deprecation rule. If it were actively
> causing problems, like complicating the build, then that might be a
> reason to break the rule. We shouldn't seek out excuses to break the
> rule.

Rules are for reasons.   The deprecation rule, I suppose, is to reduce
surprise, by giving fair warning to people using features that will be
removed.    My argument was from that point of view, but I may have
misunderstood the reason for the rule.

See you,

Matthew


From robert.kern at gmail.com  Thu May 27 20:28:32 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 May 2010 20:28:32 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
Message-ID: <AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>

On Thu, May 27, 2010 at 20:17, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
>>> However, if it is broken, then it seems to me that the user will be
>>> more likely to think that the flaw is leaving in code that is broken.
>>> ?It's also unlikely that anyone will be surprised to see it go if it
>>> hasn't worked for a long time.
>>>
>>> So - if it has not been working for at least one version, and we are
>>> not thinking of fixing it, I vote to remove. ? Does that seem
>>> reasonable?
>>
>> I see no reason to break our deprecation rule. If it were actively
>> causing problems, like complicating the build, then that might be a
>> reason to break the rule. We shouldn't seek out excuses to break the
>> rule.
>
> Rules are for reasons. ? The deprecation rule, I suppose, is to reduce
> surprise, by giving fair warning to people using features that will be
> removed. ? ?My argument was from that point of view, but I may have
> misunderstood the reason for the rule.

The reason to *follow* a rule is not the same reason for *instating*
the rule. We should follow the rules that we have agreed to because we
should make good on our promises. Otherwise, we might as well not make
those promises and make just make deprecation/removal decisions on a
case-by-case basis all the time.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu May 27 20:33:09 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 17:33:09 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
Message-ID: <AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>

> The reason to *follow* a rule is not the same reason for *instating*
> the rule. We should follow the rules that we have agreed to because we
> should make good on our promises. Otherwise, we might as well not make
> those promises and make just make deprecation/removal decisions on a
> case-by-case basis all the time.

Surely you are not saying that you follow all instantiated rules
blindly without thinking about their purpose?

Matthew


From robert.kern at gmail.com  Thu May 27 20:38:20 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 May 2010 20:38:20 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com> 
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
Message-ID: <AANLkTilxPKGXCQzYO5FUEZWOQ6_RntZDSAucIt5Que9H@mail.gmail.com>

On Thu, May 27, 2010 at 20:33, Matthew Brett <matthew.brett at gmail.com> wrote:
>> The reason to *follow* a rule is not the same reason for *instating*
>> the rule. We should follow the rules that we have agreed to because we
>> should make good on our promises. Otherwise, we might as well not make
>> those promises and make just make deprecation/removal decisions on a
>> case-by-case basis all the time.
>
> Surely you are not saying that you follow all instantiated rules
> blindly without thinking about their purpose?

I don't look for excuses to break them. I break them when it would be
Really Bad if I were to follow them. Generally, I simply try to make
good on my promises and not renege on them just because I *think* no
one will notice.

I will break rules/promises when they are in tension with other
promises. This is not such a case.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu May 27 20:39:49 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 17:39:49 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTilxPKGXCQzYO5FUEZWOQ6_RntZDSAucIt5Que9H@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
	<AANLkTilxPKGXCQzYO5FUEZWOQ6_RntZDSAucIt5Que9H@mail.gmail.com>
Message-ID: <AANLkTimtN8QrhhnNvX5FjaJu_wTUNLxy-r_rxFxC2Aov@mail.gmail.com>

> I will break rules/promises when they are in tension with other
> promises. This is not such a case.

I fully accept your ruling on the matter ;)

Matthew


From david at silveregg.co.jp  Thu May 27 20:46:03 2010
From: david at silveregg.co.jp (David)
Date: Fri, 28 May 2010 09:46:03 +0900
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
Message-ID: <4BFF124B.5050704@silveregg.co.jp>

On 05/28/2010 07:20 AM, Matthew Brett wrote:
> Hi,
>
>> 1. Fix it and deprecate it.
>> 2. Deprecate it, but don't bother fixing it.
>> 3. Remove it without bothering with a cycle of deprecation.
>
>> My initial preference was for #3, but David C. suggested sticking with
>> the deprecation policy, which is fine with me.  I'll just remove it next
>> week, after 0.8 is branched, so it will be gone in 0.9.  So, revision
>> r6416 assumes #2.
>
> The deprecation would be because someone may have been using it, and
> they would be surprised to see it has gone, and that surprise would
> seem to them to be a flaw in scipy.  We want to avoid that.
>
> However, if it is broken, then it seems to me that the user will be
> more likely to think that the flaw is leaving in code that is broken.
>   It's also unlikely that anyone will be surprised to see it go if it
> hasn't worked for a long time.

There is no way to gauge the unlikeness, and I think as a developer, you 
almost always underestimate the cost. Maybe some users have a 
monkey-patch version of the module, who knows.

> So - if it has not been working for at least one version, and we are
> not thinking of fixing it, I vote to remove.   Does that seem
> reasonable?

It does not to me. Keeping python code has *no* cost from a maintainance 
point of view (contrary to compiled code which may be a pain to allow it 
to build), so there should be a really good reason to *remove* it, not a 
good reason to *keep* it.

cheers,

David


From robert.kern at gmail.com  Thu May 27 20:56:42 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 May 2010 20:56:42 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com> 
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
Message-ID: <AANLkTimavIEqRsec_RSWjCz1MrpZUtZCPKpPhExEliNM@mail.gmail.com>

On Thu, May 27, 2010 at 20:33, Matthew Brett <matthew.brett at gmail.com> wrote:
>> The reason to *follow* a rule is not the same reason for *instating*
>> the rule. We should follow the rules that we have agreed to because we
>> should make good on our promises. Otherwise, we might as well not make
>> those promises and make just make deprecation/removal decisions on a
>> case-by-case basis all the time.
>
> Surely you are not saying that you follow all instantiated rules
> blindly without thinking about their purpose?

I think we've come to an agreement about the issue at hand, but I
would like to add a little bit in response to this.

There is a distinction between decisions and policies. The reason we
decide to deprecate individual things for a release is to provide
warnings to actual users that things will be going away. The reason
that we have a policy of *always* deprecating things for one release
before they go away is such that we don't have to have these
discussions about whether or not they have actual users or if it would
be safe to just change it immediately. It's just a discussion that's
not worth having. So what if we go through the full deprecation
process for some things that we didn't strictly have to? No big deal.
The less thinking I have to do about things that don't matter, the
better I feel. Glyph Lefkowitz likens this to the rigorous Suzuki
Method of learning violin:

  http://glyf.livejournal.com/58626.html

There are exceptions, of course, but the ones that are worth breaking
a policy for are really obvious and won't be blindly ignored just
because we have a policy.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From warren.weckesser at enthought.com  Thu May 27 20:58:11 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Thu, 27 May 2010 19:58:11 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFF124B.5050704@silveregg.co.jp>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>	<4BFD7B58.3070906@enthought.com>	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>	<4BFDC44D.9070008@silveregg.co.jp>
	<4BFE7F4A.7010805@enthought.com>	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>	<4BFEEEB3.9050602@enthought.com>	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<4BFF124B.5050704@silveregg.co.jp>
Message-ID: <4BFF1523.4030505@enthought.com>

David wrote:
> On 05/28/2010 07:20 AM, Matthew Brett wrote:
>   
>> Hi,
>>
>>     
>>> 1. Fix it and deprecate it.
>>> 2. Deprecate it, but don't bother fixing it.
>>> 3. Remove it without bothering with a cycle of deprecation.
>>>       
>>> My initial preference was for #3, but David C. suggested sticking with
>>> the deprecation policy, which is fine with me.  I'll just remove it next
>>> week, after 0.8 is branched, so it will be gone in 0.9.  So, revision
>>> r6416 assumes #2.
>>>       
>> The deprecation would be because someone may have been using it, and
>> they would be surprised to see it has gone, and that surprise would
>> seem to them to be a flaw in scipy.  We want to avoid that.
>>
>> However, if it is broken, then it seems to me that the user will be
>> more likely to think that the flaw is leaving in code that is broken.
>>   It's also unlikely that anyone will be surprised to see it go if it
>> hasn't worked for a long time.
>>     
>
> There is no way to gauge the unlikeness, and I think as a developer, you 
> almost always underestimate the cost. Maybe some users have a 
> monkey-patch version of the module, who knows.
>
>   
>> So - if it has not been working for at least one version, and we are
>> not thinking of fixing it, I vote to remove.   Does that seem
>> reasonable?
>>     
>
>   


I'm perfectly happy with deprecating, for all the reasons Robert and 
David have mentioned.


> It does not to me. Keeping python code has *no* cost from a maintainance 
> point of view (contrary to compiled code which may be a pain to allow it 
> to build),


Since you specifically emphasized "no", I will respectfully disagree 
with you about that.  I spent time fixing a bug in ppimport, before I 
knew that it was deprecated and no longer had a use in scipy--and that 
it had additional problems besides the small ones I fixed.  My questions 
about ppimport took up time of other developers.  Developers' time is a 
cost.  Code that is not going to be maintained, or that no longer solves 
a problem within the scope of SciPy, should be removed.

But not until is has been deprecated for at least one release. :)

Warren


>  so there should be a really good reason to *remove* it, not a 
> good reason to *keep* it.
>
> cheers,
>
> David
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From robert.kern at gmail.com  Thu May 27 21:00:32 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 27 May 2010 21:00:32 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <4BFF1523.4030505@enthought.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<4BFF124B.5050704@silveregg.co.jp> <4BFF1523.4030505@enthought.com>
Message-ID: <AANLkTikT4BzWbyG80huwGKWY4BeoD7X1ZDqaqzOLx5Qh@mail.gmail.com>

On Thu, May 27, 2010 at 20:58, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> David wrote:

>> It does not to me. Keeping python code has *no* cost from a maintainance
>> point of view (contrary to compiled code which may be a pain to allow it
>> to build),
>
> Since you specifically emphasized "no", I will respectfully disagree
> with you about that. ?I spent time fixing a bug in ppimport, before I
> knew that it was deprecated and no longer had a use in scipy--and that
> it had additional problems besides the small ones I fixed. ?My questions
> about ppimport took up time of other developers. ?Developers' time is a
> cost. ?Code that is not going to be maintained, or that no longer solves
> a problem within the scope of SciPy, should be removed.
>
> But not until is has been deprecated for at least one release. :)

"Keeping [properly-marked-deprecated] python code has *no* cost from a
maintenance point of view ...."

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Thu May 27 21:11:28 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Thu, 27 May 2010 18:11:28 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTimavIEqRsec_RSWjCz1MrpZUtZCPKpPhExEliNM@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
	<AANLkTimavIEqRsec_RSWjCz1MrpZUtZCPKpPhExEliNM@mail.gmail.com>
Message-ID: <AANLkTinZ7q2TCSLjJqiZEj7BnJYj8fv_7m-o7gLt98rJ@mail.gmail.com>

Hi,

> The less thinking I have to do about things that don't matter, the
> better I feel. Glyph Lefkowitz likens this to the rigorous Suzuki
> Method of learning violin:
>
> ?http://glyf.livejournal.com/58626.html
>
> There are exceptions, of course, but the ones that are worth breaking
> a policy for are really obvious and won't be blindly ignored just
> because we have a policy.

Right.  Thanks - that's interesting and helpful.

>From my side, I only ask, humbly, for something less abrasive as a
first response.   I mean, instead of 'I see no reason...', something
like, 'I don't think your argument justifies...'  The second is
absolutely fair enough, and the first implies that I was talking
nonsense.  Which you're welcome to imply of course, and if I'd had
less coffee, I'm sure I would not have replied ;)

Matthew


From charlesr.harris at gmail.com  Thu May 27 21:37:43 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 27 May 2010 19:37:43 -0600
Subject: [SciPy-Dev] non-negative matrix factorization
Message-ID: <AANLkTilzG5AbxqDjj7V32FgbXO_RALfq7nBSf7MtMZqX@mail.gmail.com>

Hi All,

Does anyone know of a python or scipy version of non-negative matrix
factorization<http://en.wikipedia.org/wiki/Non-negative_matrix_factorization>
?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/2c61806f/attachment.html>

From josef.pktd at gmail.com  Thu May 27 21:50:24 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Thu, 27 May 2010 21:50:24 -0400
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTikT4BzWbyG80huwGKWY4BeoD7X1ZDqaqzOLx5Qh@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<4BFF124B.5050704@silveregg.co.jp> <4BFF1523.4030505@enthought.com>
	<AANLkTikT4BzWbyG80huwGKWY4BeoD7X1ZDqaqzOLx5Qh@mail.gmail.com>
Message-ID: <AANLkTikkjtFMKtNwIF3kVwr54QrwYxg9unxIMtKzs-0W@mail.gmail.com>

On Thu, May 27, 2010 at 9:00 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On Thu, May 27, 2010 at 20:58, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>> David wrote:
>
>>> It does not to me. Keeping python code has *no* cost from a maintainance
>>> point of view (contrary to compiled code which may be a pain to allow it
>>> to build),
>>
>> Since you specifically emphasized "no", I will respectfully disagree
>> with you about that. ?I spent time fixing a bug in ppimport, before I
>> knew that it was deprecated and no longer had a use in scipy--and that
>> it had additional problems besides the small ones I fixed. ?My questions
>> about ppimport took up time of other developers. ?Developers' time is a
>> cost. ?Code that is not going to be maintained, or that no longer solves
>> a problem within the scope of SciPy, should be removed.
>>
>> But not until is has been deprecated for at least one release. :)
>
> "Keeping [properly-marked-deprecated] python code has *no* cost from a
> maintenance point of view ...."

So, is there a policy that applies to morestats.pdf_moments, it just
returns the normal distribution, no change in skew nor kurtosis,
anyone using the function doesn't get what's promised in almost every
case.

kill the function or not?

Josef


> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
> ?-- Umberto Eco
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>


From stefan at sun.ac.za  Thu May 27 22:08:18 2010
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Thu, 27 May 2010 19:08:18 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
Message-ID: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>

On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
> The reason to *follow* a rule is not the same reason for *instating*
> the rule. We should follow the rules that we have agreed to because we
> should make good on our promises. Otherwise, we might as well not make
> those promises and make just make deprecation/removal decisions on a
> case-by-case basis all the time.

Sure, that makes sense except that the rule never envisioned this
situation: deprecation of a broken function.  What do we do: raise a
deprecationwarning and then proceed to let the broken code run?
David's argument about monkeypatching also doesn't make much sense to
me: if a user monkey-patched ppimport, how will deprecation help?

If we deprecate, we have to fix the function to at least return a valid result.

Regards
St?fan


From charlesr.harris at gmail.com  Thu May 27 22:19:08 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 27 May 2010 20:19:08 -0600
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
Message-ID: <AANLkTimWKSwj6LujgueZQE87aoKXIo3xuewj4MCPpv9Q@mail.gmail.com>

2010/5/27 St?fan van der Walt <stefan at sun.ac.za>

> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
> > The reason to *follow* a rule is not the same reason for *instating*
> > the rule. We should follow the rules that we have agreed to because we
> > should make good on our promises. Otherwise, we might as well not make
> > those promises and make just make deprecation/removal decisions on a
> > case-by-case basis all the time.
>
> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.  What do we do: raise a
> deprecationwarning and then proceed to let the broken code run?
> David's argument about monkeypatching also doesn't make much sense to
> me: if a user monkey-patched ppimport, how will deprecation help?
>
> If we deprecate, we have to fix the function to at least return a valid
> result.
>
>

How about a deprecation warning that also says the function is broken?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/fe9b1c11/attachment.html>

From charlesr.harris at gmail.com  Thu May 27 22:19:40 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 27 May 2010 20:19:40 -0600
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
Message-ID: <AANLkTik_DWuCGz_4lrSXyJGdoEaMRWMeaAwzsOL5r04d@mail.gmail.com>

2010/5/27 St?fan van der Walt <stefan at sun.ac.za>

> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
> > The reason to *follow* a rule is not the same reason for *instating*
> > the rule. We should follow the rules that we have agreed to because we
> > should make good on our promises. Otherwise, we might as well not make
> > those promises and make just make deprecation/removal decisions on a
> > case-by-case basis all the time.
>
> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.  What do we do: raise a
> deprecationwarning and then proceed to let the broken code run?
> David's argument about monkeypatching also doesn't make much sense to
> me: if a user monkey-patched ppimport, how will deprecation help?
>
> If we deprecate, we have to fix the function to at least return a valid
> result.
>
>

How about a deprecation warning that also says the function is broken?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/2f126522/attachment.html>

From charlesr.harris at gmail.com  Thu May 27 22:19:08 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Thu, 27 May 2010 20:19:08 -0600
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
Message-ID: <AANLkTimWKSwj6LujgueZQE87aoKXIo3xuewj4MCPpv9Q@mail.gmail.com>

2010/5/27 St?fan van der Walt <stefan at sun.ac.za>

> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
> > The reason to *follow* a rule is not the same reason for *instating*
> > the rule. We should follow the rules that we have agreed to because we
> > should make good on our promises. Otherwise, we might as well not make
> > those promises and make just make deprecation/removal decisions on a
> > case-by-case basis all the time.
>
> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.  What do we do: raise a
> deprecationwarning and then proceed to let the broken code run?
> David's argument about monkeypatching also doesn't make much sense to
> me: if a user monkey-patched ppimport, how will deprecation help?
>
> If we deprecate, we have to fix the function to at least return a valid
> result.
>
>

How about a deprecation warning that also says the function is broken?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100527/fe9b1c11/attachment-0001.html>

From david at silveregg.co.jp  Thu May 27 23:04:22 2010
From: david at silveregg.co.jp (David)
Date: Fri, 28 May 2010 12:04:22 +0900
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
Message-ID: <4BFF32B6.8040604@silveregg.co.jp>

On 05/28/2010 11:08 AM, St?fan van der Walt wrote:

> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.  What do we do: raise a
> deprecationwarning and then proceed to let the broken code run?
> David's argument about monkeypatching also doesn't make much sense to
> me: if a user monkey-patched ppimport, how will deprecation help?

He will know that scipy will remove this function at some point, and can 
act accordingly in his code. If we just remove it, there will be some 
time where his code will be broken. Removing so called 
broken/unused/private functions without deprecation is what happens 
sometimes with distribute - I *really* hate it, it is poor engineering 
practice.

cheers,

David


From cournape at gmail.com  Fri May 28 04:21:00 2010
From: cournape at gmail.com (David Cournapeau)
Date: Fri, 28 May 2010 17:21:00 +0900
Subject: [SciPy-Dev] non-negative matrix factorization
In-Reply-To: <AANLkTilzG5AbxqDjj7V32FgbXO_RALfq7nBSf7MtMZqX@mail.gmail.com>
References: <AANLkTilzG5AbxqDjj7V32FgbXO_RALfq7nBSf7MtMZqX@mail.gmail.com>
Message-ID: <AANLkTimsm4SLYftVMuw-L_sJAUwNInnL_HCS8N7AIKOb@mail.gmail.com>

On Fri, May 28, 2010 at 10:37 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> Hi All,
>
> Does anyone know of a python or scipy version of non-negative matrix
> factorization?

You can look at this, which is one of the possible method (there is
the papers somewhere on the website as well)

http://www.csie.ntu.edu.tw/~cjlin/nmf/others/nmf.py

cheers,

David


From d.l.goldsmith at gmail.com  Fri May 28 05:14:19 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 28 May 2010 02:14:19 -0700
Subject: [SciPy-Dev] Today's Summer Marathon Skypecon canceled
Message-ID: <AANLkTinIocCYjfasF7paWnqn9wC1U-VZrkigv3zyN5Xm@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100528/5e1fcb80/attachment.html>

From matthew.brett at gmail.com  Sat May 29 00:12:57 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Fri, 28 May 2010 21:12:57 -0700
Subject: [SciPy-Dev] io/matlab test errors
In-Reply-To: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
References: <AANLkTilKs78dOZfMnUJyHMDMykaCmZuKQryW-lL3ZHya@mail.gmail.com>
Message-ID: <AANLkTinaKKmsGfUkJxe4WzKqp4GwwlW0g4kOqbW24ckr@mail.gmail.com>

Hi,

On Thu, May 27, 2010 at 11:32 AM,  <josef.pktd at gmail.com> wrote:
> does anyone get these? ?WindosXP32, numpy 1.4.0, scipy 0.8.0.dev6416

They should be fixed as of r6419 ?

It was mostly the age-old opening files as text mode difference.   I
keep forgetting.

Thanks a lot,

Matthew

> ======================================================================
> ERROR: Failure: TypeError (Expecting miMATRIX type here, got 3917)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 224, in generate
> ? ?for test in g():
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
> , line 718, in test_func_read
> ? ?d = rdr.get_variables()
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
> ?in get_variables
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
> ?in read_var_header
> TypeError: Expecting miMATRIX type here, got 3917
>
> ======================================================================
> ERROR: Failure: TypeError (Expecting miMATRIX type here, got 1224736768)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 224, in generate
> ? ?for test in g():
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio.py"
> , line 728, in test_mat_dtype
> ? ?d = rdr.get_variables()
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
> ?in get_variables
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 372,
> ?in read_var_header
> TypeError: Expecting miMATRIX type here, got 1224736768
>
> ======================================================================
> ERROR: Failure: error (Error -3 while decompressing: invalid distance too far ba
> ck)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\loader
> .py", line 379, in loadTestsFromName
> ? ?addr.filename, addr.module)
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
> er.py", line 39, in importFromPath
> ? ?return self.importFromDir(dir_path, fqname)
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\import
> er.py", line 86, in importFromDir
> ? ?mod = load_module(part_fqname, fh, filename, desc)
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
> cs.py", line 57, in <module>
> ? ?ws_vars = read_workspace_vars(fname)
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_mio_fun
> cs.py", line 44, in read_workspace_vars
> ? ?vars = rdr.get_variables()
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 410,
> ?in get_variables
> ?File "\Programs\Python25\Lib\site-packages\scipy\io\matlab\mio5.py", line 362,
> ?in read_var_header
> error: Error -3 while decompressing: invalid distance too far back
>
> ======================================================================
> ERROR: test suite for <module 'test_streams' from 'C:\Josef\_progs\Subversion\sc
> ipy-trunk_after\trunk\dist\scipy-0.8.0.dev6416.win32\Programs\Python25\Lib\site-
> packages\scipy\io\matlab\tests\test_streams.pyc'>
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 201, in run
> ? ?self.tearDown()
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 323, in tearDown
> ? ?self.teardownContext(ancestor)
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\suite.
> py", line 339, in teardownContext
> ? ?try_run(context, names)
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\util.p
> y", line 487, in try_run
> ? ?return func()
> ?File "C:\Josef\_progs\Subversion\scipy-trunk_after\trunk\dist\scipy-0.8.0.dev6
> 416.win32\Programs\Python25\Lib\site-packages\scipy\io\matlab\tests\test_streams
> .py", line 37, in teardown
> ? ?os.unlink(fname)
> WindowsError: [Error 32] The process cannot access the file because it is being
> used by another process: 'c:\\docume~1\\josef\\locals~1\\temp\\tmpcx8egl'
>
> ======================================================================
> FAIL: test_mio_utils.test_squeeze_element(False,)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
> ?File "c:\programs\python25\lib\site-packages\nose-0.11.1-py2.5.egg\nose\case.p
> y", line 183, in runTest
> ? ?self.test(*self.arg)
> AssertionError
>
> ----------------------------------------------------------------------
> Ran 386 tests in 2.328s


From d.l.goldsmith at gmail.com  Sat May 29 01:13:05 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Fri, 28 May 2010 22:13:05 -0700
Subject: [SciPy-Dev] Do we have docstring Standards for objects "above"
	classes/functions?
Message-ID: <AANLkTil_o6HNirHoK1spieYzZLXRpXR5QYxRRlyKqcSy@mail.gmail.com>

i.e., modules, sub-packages, packages (have I forgotten anything?)
Semi-rhetorical follow-up: should we develop/promulgate some?  (I don't
_think_ there's presently any consistency in this regard in SciPy; I _hope_
there is in NumPy, though I wouldn't stake my life on it.)

DG

-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100528/d4a2f216/attachment.html>

From warren.weckesser at enthought.com  Sat May 29 11:00:14 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 29 May 2010 10:00:14 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
Message-ID: <4C012BFE.4090103@enthought.com>

Over the last several months, I've changed the API of few function in 
ways that are not compatible with the previous behavior.  These are:

constants.find
    It now returns a list instead of printing it. 
(http://projects.scipy.org/scipy/ticket/996)

linalg.solveh_banded
    It now returns just the solution, instead of the tuple containing 
the solution and the cholesky factor. 
(http://projects.scipy.org/scipy/ticket/676)

signal.chirp
    Removed one keyword argument and added a new keyword argument.  
Also, it no longer handles a polynomial (or polynomial-like) argument.  
(http://projects.scipy.org/scipy/ticket/1105, but the API changes are 
not actually related to the problem reported there.)


The recent discussion about deprecation and ppimport reminded me that 
these changes should be deprecated for one release.

What I would like to do is leave trunk as it is, and after 0.8 is 
branched, make the appropriate changes in the branch to follow the 
deprecation policy.  Is that a reasonable approach?


Warren



From cournape at gmail.com  Sat May 29 12:12:51 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 30 May 2010 01:12:51 +0900
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C012BFE.4090103@enthought.com>
References: <4C012BFE.4090103@enthought.com>
Message-ID: <AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>

On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:


> What I would like to do is leave trunk as it is, and after 0.8 is
> branched, make the appropriate changes in the branch to follow the
> deprecation policy. ?Is that a reasonable approach?

May I ask why do you want to do that way ? Putting the deprecation in
the release branch means people tracking trunk will never see them.
Unless you have a good reason for it, I would prefer seeing those
changes in the trunk first,

cheers,

David


From warren.weckesser at enthought.com  Sat May 29 13:07:55 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 29 May 2010 12:07:55 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
Message-ID: <4C0149EB.8030608@enthought.com>

David Cournapeau wrote:
> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>
>
>   
>> What I would like to do is leave trunk as it is, and after 0.8 is
>> branched, make the appropriate changes in the branch to follow the
>> deprecation policy.  Is that a reasonable approach?
>>     
>
> May I ask why do you want to do that way ?

Because it doesn't look like I will have time to make the changes before 
Ralf branches 0.8 tomorrow.

>  Putting the deprecation in
> the release branch means people tracking trunk will never see them.
>   

Good point.    But in case I am misinterpreting what you mean by 
"tracking trunk" and "see":  I assume this means it is important to have 
a record of the deprecation changes in the svn logs, and not that some 
who is *using* scipy from trunk also needs to be exposed to the 
deprecation warning for some minimum amount of time.  If the changes are 
made to trunk, then they will be undone immediately after 0.8 is 
branched.  So someone who updates from trunk every week or so might not 
ever have a copy that includes the deprecation warnings.  In other 
words, deprecations are linked to releases, not to "time in trunk".  If 
my interpretation is wrong, let me know.

Warren

> Unless you have a good reason for it, I would prefer seeing those
> changes in the trunk first,
>
> cheers,
>
> David
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From d.l.goldsmith at gmail.com  Sat May 29 13:21:45 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sat, 29 May 2010 10:21:45 -0700
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C012BFE.4090103@enthought.com>
References: <4C012BFE.4090103@enthought.com>
Message-ID: <AANLkTinX6jjEUqXspX4BcL944YgeC87mcP64XMoLrqNX@mail.gmail.com>

I trust you changed their docstrings accordingly?

DG

On Sat, May 29, 2010 at 8:00 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Over the last several months, I've changed the API of few function in
> ways that are not compatible with the previous behavior.  These are:
>
> constants.find
>    It now returns a list instead of printing it.
> (http://projects.scipy.org/scipy/ticket/996)
>
> linalg.solveh_banded
>    It now returns just the solution, instead of the tuple containing
> the solution and the cholesky factor.
> (http://projects.scipy.org/scipy/ticket/676)
>
> signal.chirp
>    Removed one keyword argument and added a new keyword argument.
> Also, it no longer handles a polynomial (or polynomial-like) argument.
> (http://projects.scipy.org/scipy/ticket/1105, but the API changes are
> not actually related to the problem reported there.)
>
>
> The recent discussion about deprecation and ppimport reminded me that
> these changes should be deprecated for one release.
>
> What I would like to do is leave trunk as it is, and after 0.8 is
> branched, make the appropriate changes in the branch to follow the
> deprecation policy.  Is that a reasonable approach?
>
>
> Warren
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100529/e45b2934/attachment.html>

From warren.weckesser at enthought.com  Sat May 29 13:31:51 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 29 May 2010 12:31:51 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTinX6jjEUqXspX4BcL944YgeC87mcP64XMoLrqNX@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinX6jjEUqXspX4BcL944YgeC87mcP64XMoLrqNX@mail.gmail.com>
Message-ID: <4C014F87.3080506@enthought.com>

David Goldsmith wrote:
> I trust you changed their docstrings accordingly?

Yes, and made note of the changes in the release notes.

Warren

>
> DG
>
> On Sat, May 29, 2010 at 8:00 AM, Warren Weckesser 
> <warren.weckesser at enthought.com 
> <mailto:warren.weckesser at enthought.com>> wrote:
>
>     Over the last several months, I've changed the API of few function in
>     ways that are not compatible with the previous behavior.  These are:
>
>     constants.find
>        It now returns a list instead of printing it.
>     (http://projects.scipy.org/scipy/ticket/996)
>
>     linalg.solveh_banded
>        It now returns just the solution, instead of the tuple containing
>     the solution and the cholesky factor.
>     (http://projects.scipy.org/scipy/ticket/676)
>
>     signal.chirp
>        Removed one keyword argument and added a new keyword argument.
>     Also, it no longer handles a polynomial (or polynomial-like) argument.
>     (http://projects.scipy.org/scipy/ticket/1105, but the API changes are
>     not actually related to the problem reported there.)
>
>
>     The recent discussion about deprecation and ppimport reminded me that
>     these changes should be deprecated for one release.
>
>     What I would like to do is leave trunk as it is, and after 0.8 is
>     branched, make the appropriate changes in the branch to follow the
>     deprecation policy.  Is that a reasonable approach?
>
>
>     Warren
>
>     _______________________________________________
>     SciPy-Dev mailing list
>     SciPy-Dev at scipy.org <mailto:SciPy-Dev at scipy.org>
>     http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
>
> -- 
> Mathematician: noun, someone who disavows certainty when their 
> uncertainty set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with 
> her lies, prevents mankind from committing a general suicide.  (As 
> interpreted by Robert Graves)
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From cournape at gmail.com  Sat May 29 13:36:01 2010
From: cournape at gmail.com (David Cournapeau)
Date: Sun, 30 May 2010 02:36:01 +0900
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C0149EB.8030608@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
Message-ID: <AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>

On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> David Cournapeau wrote:
>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>> <warren.weckesser at enthought.com> wrote:
>>
>>
>>
>>> What I would like to do is leave trunk as it is, and after 0.8 is
>>> branched, make the appropriate changes in the branch to follow the
>>> deprecation policy. ?Is that a reasonable approach?
>>>
>>
>> May I ask why do you want to do that way ?
>
> Because it doesn't look like I will have time to make the changes before
> Ralf branches 0.8 tomorrow.
>
>> ?Putting the deprecation in
>> the release branch means people tracking trunk will never see them.
>>
>
> Good point. ? ?But in case I am misinterpreting what you mean by
> "tracking trunk" and "see": ?I assume this means it is important to have
> a record of the deprecation changes in the svn logs, and not that some
> who is *using* scipy from trunk also needs to be exposed to the
> deprecation warning for some minimum amount of time.

actually, I meant both. For example, I often use scipy from trunk, and
rarely from releases.  I will never see the deprecation, which is not
good.

Also, I think we should generally try to never put things in release
branches, but always backport from trunk (except for branch specific
changes). Having the 0.8 branch created tomorrow does not mean you
cannot put the changes into trunk, and backport them in 0.8 later -
deprecation which were already agreed on are the kind of things which
can happen after the branching without putting much burden on the
release process.

>?If the changes are
> made to trunk, then they will be undone immediately after 0.8 is
> branched.

deprecated features do not be to be removed just after the trunk is
opened for the next release cycle (0.9 here).

> ever have a copy that includes the deprecation warnings. ?In other
> words, deprecations are linked to releases, not to "time in trunk".

Indeed - but I think that we should let the deprecation be in place
for as long as possible in the source code repository.

cheers,

David


From robert.kern at gmail.com  Sat May 29 14:36:33 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 29 May 2010 13:36:33 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com> 
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
Message-ID: <AANLkTim-i3II1wiCnJrKoc18ACSP0Auomle4urw-kaoN@mail.gmail.com>

2010/5/27 St?fan van der Walt <stefan at sun.ac.za>:
> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
>> The reason to *follow* a rule is not the same reason for *instating*
>> the rule. We should follow the rules that we have agreed to because we
>> should make good on our promises. Otherwise, we might as well not make
>> those promises and make just make deprecation/removal decisions on a
>> case-by-case basis all the time.
>
> Sure, that makes sense except that the rule never envisioned this
> situation: deprecation of a broken function.

We sort of did, actually. IIRC, the big issue that led to the
formation of the policy was the old np.histogram behavior. It was
argued that what it calculated was nothing anyone would actually want
so we would simply replace the behavior with a more correct one (after
a series of deprecations). It's a slightly different kind of
brokenness, but the logic is mostly the same.

> If we deprecate, we have to fix the function to at least return a valid result.

No, we don't. We mark it deprecated so we don't have to waste time
fixing it or improving it.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Sat May 29 14:37:19 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 May 2010 11:37:19 -0700
Subject: [SciPy-Dev] Problem building html docs
In-Reply-To: <AANLkTilE1V-MrruGWDQHgVyfbiWB0DVT1DSmumkB2GVa@mail.gmail.com>
References: <4BFAAE3E.50907@enthought.com>
	<AANLkTimDMTKDmgITfj4-ORZlfDgHScwFcMVTnXGymCZ2@mail.gmail.com>
	<4BFADC92.6070602@enthought.com>
	<AANLkTilVg06cvhONtq65OAecOojI774mOtebQHsKT3kf@mail.gmail.com>
	<4BFB561C.3000300@enthought.com>
	<AANLkTilE1V-MrruGWDQHgVyfbiWB0DVT1DSmumkB2GVa@mail.gmail.com>
Message-ID: <AANLkTil0JLrb_g_CoElxokVSvvVjwXv3aj-nifejCdnA@mail.gmail.com>

Hi Ralf,

> Thanks for fixing that Warren. Guess in this case it wasn't enough that the
> patch looks fine and applied cleanly.
>
> By the way, does anyone have a reasonable way with git to get the sphinxext
> stuff from numpy that svn pulls in via externals? This is the reason that
> the docs don't build out of the box in a git repo. And can I add
> /doc/sphinxext to .gitignore?

Sorry - I missed this one - and I am no expert at this, but:

There are a few options for this kind of thing in git - but they are
not as straightforward as svn externals.

The reason for the difficulty is that svn thinks of every directory as
being a separate versioned thing, whereas git thinks in terms of whole
trees.    As a symptom of same, git has one .git subdirectory at the
root level of your project, containing the repository information, and
svn has .svn files in each subdirectory of the tree.

The first is to use a git submodule: http://book.git-scm.com/5_submodules.html

In this case the external thing you want to include is a whole
repository - one repository for the sphinext directory.   It might
look something like:

cd my-numpy-git-repo/doc
git submodule add git://github.com/my-user/numpy-sphinxexts.git sphinext
git commit -am 'Added sphinxext repository as submodule'

This all fine for you, the creator, but anyone cloning your repo has
to remember to do this:

git clone git://github/my-user/my-numpy-git-repo.git
cd my-numpy-git-repo
git submodule init
git submodule update

in order to get the actual files in their tree...  Having said that,
it does have the benefit of keeping track of the particular revision
(commit) of the tree that you are using.

The second option is to use a subtree merge:

http://help.github.com/subtree-merge/
http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html

Again, this requires an entire repository for the thing you want to
include.  I think like this:

git remote add sphinext-remote git://github.com/my-user/numpy-sphinxexts.git
git fetch sphinext-remote
git merge -s ours --no-commit sphinxext-remote/master
git read-tree --prefix=sphinxext-dir -u sphinext-remote/master
git commit -am 'Subtree merge of sphinxext docs'

At this stage you have the entire contents of the sphinxext repository
in your repo, in the 'sphinext-dir' directory, and you have merged the
histories of your repo and the sphinxext repo.  (You can avoid merging
the histories if you want  using the --squash option) - see
http://progit.org/book/ch6-7.html)

Now, whenever someone clones, they get the whole tree, including the
sphinxext docs - and that's the advantage of this approach.

To update the sphinext directory (and your repository history):

git pull -s subtree sphinxext-remote master

See: http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html
for a discussion of subtree merge vs submodules.

There's an example of subtree merge here:
http://github.com/matthew-brett/gitwash-includer

Lastly - the download-it-yourself git subtree command :
http://github.com/apenwarr/git-subtree - does allow you to link to
subdirectories of a repository :
http://psionides.jogger.pl/2010/02/04/sharing-code-between-projects-with-git-subtree/
 .  It looks like it works like this:

In some repository 'containing-project' that has 'sphinxext' as a subdirectory:

cd containing-project
git subtree split --prefix path/to/sphinxext --branch sphinext-only

Now you have a new branch in this repository containing only the files
from the path/to/sphinxext directory, and the history of those files -
only.  You can then use this subtree as the target for your submodule
or subtree merge... - i.e:

git submodule add --branch sphinxext-only
git://github.com/my-user/containing-project.git sphinext

or

git remote add sphinext-remote git://github.com/my-user/containing-project.git
git fetch sphinext-remote
git merge -s ours --no-commit sphinxext-remote/sphinxext-only
git read-tree --prefix=sphinxext-dir -u sphinext-remote/sphinxext-only

I think the combination of the subtree command and the subtree merge
with --squash is the closest to the svn externals routine...

See you,

Matthew


From robert.kern at gmail.com  Sat May 29 14:40:42 2010
From: robert.kern at gmail.com (Robert Kern)
Date: Sat, 29 May 2010 13:40:42 -0500
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTinZ7q2TCSLjJqiZEj7BnJYj8fv_7m-o7gLt98rJ@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com> 
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com> 
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com> 
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com> 
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com> 
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com> 
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com> 
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com> 
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com> 
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com> 
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com> 
	<AANLkTimavIEqRsec_RSWjCz1MrpZUtZCPKpPhExEliNM@mail.gmail.com> 
	<AANLkTinZ7q2TCSLjJqiZEj7BnJYj8fv_7m-o7gLt98rJ@mail.gmail.com>
Message-ID: <AANLkTil2tp2XKzyK07xnDoZFvkUY3zTgrKqN_GQ_6BU5@mail.gmail.com>

On Thu, May 27, 2010 at 20:11, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
>> The less thinking I have to do about things that don't matter, the
>> better I feel. Glyph Lefkowitz likens this to the rigorous Suzuki
>> Method of learning violin:
>>
>> ?http://glyf.livejournal.com/58626.html
>>
>> There are exceptions, of course, but the ones that are worth breaking
>> a policy for are really obvious and won't be blindly ignored just
>> because we have a policy.
>
> Right. ?Thanks - that's interesting and helpful.
>
> >From my side, I only ask, humbly, for something less abrasive as a
> first response. ? I mean, instead of 'I see no reason...', something
> like, 'I don't think your argument justifies...' ?The second is
> absolutely fair enough, and the first implies that I was talking
> nonsense. ?Which you're welcome to imply of course, and if I'd had
> less coffee, I'm sure I would not have replied ;)

I apologize. I try very hard to write very precisely in plain language
and avoid rhetorical devices. I simply meant that I, personally, did
not see a justification for breaking the rule. I did not mean to imply
that one could not exist.

Where I run into problems is where the plain meaning of a phrase
usually used as a rhetorical device to emotionally bludgeon one's
conversant happens to match what I'm trying to say.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
  -- Umberto Eco


From matthew.brett at gmail.com  Sat May 29 14:51:37 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 May 2010 11:51:37 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTim-i3II1wiCnJrKoc18ACSP0Auomle4urw-kaoN@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTil-SqsQOBFYmFvKjWblD5gJcPokeJMhz-3cxYk_@mail.gmail.com>
	<AANLkTim-i3II1wiCnJrKoc18ACSP0Auomle4urw-kaoN@mail.gmail.com>
Message-ID: <AANLkTimtdh4q_JOZHAceS-ozGJdpGGtpth6pfhLsBS_Z@mail.gmail.com>

Hi,

On Sat, May 29, 2010 at 11:36 AM, Robert Kern <robert.kern at gmail.com> wrote:
> 2010/5/27 St?fan van der Walt <stefan at sun.ac.za>:
>> On 27 May 2010 17:28, Robert Kern <robert.kern at gmail.com> wrote:
>>> The reason to *follow* a rule is not the same reason for *instating*
>>> the rule. We should follow the rules that we have agreed to because we
>>> should make good on our promises. Otherwise, we might as well not make
>>> those promises and make just make deprecation/removal decisions on a
>>> case-by-case basis all the time.
>>
>> Sure, that makes sense except that the rule never envisioned this
>> situation: deprecation of a broken function.

It seems to me the situation is clear

a) There is an argument for removing without deprecation
b) There's a prior rule to deprecate that we have to take into account
c) Someone has to make the call
d) Robert has made the call.

My suggestion for avoiding getting lost in discussion is just to make
all these things clear.  By all-these-things I mean also that there is
a coherent contrary argument.   If we start there, I think we all
agree that the sequence is right...

See you,

Matthew


From matthew.brett at gmail.com  Sat May 29 14:59:55 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 May 2010 11:59:55 -0700
Subject: [SciPy-Dev] deprecations - things to remove before 0.8.0
In-Reply-To: <AANLkTil2tp2XKzyK07xnDoZFvkUY3zTgrKqN_GQ_6BU5@mail.gmail.com>
References: <AANLkTik7ny-Ja9uAEjA2LBjm7v7vzfaHyP3WAr2yzQJR@mail.gmail.com>
	<4BFD7B58.3070906@enthought.com>
	<AANLkTimrVF3NcClwO5xUjMOnPb-1HNesPF6VuWXhdYMv@mail.gmail.com>
	<AANLkTikA9wRFSKmFYptDF0t_cEdN1P87lomdDzgWQJmw@mail.gmail.com>
	<AANLkTinaXDUhqJduUpTAJXgFHJS0LXqzJnLoNRu54KdQ@mail.gmail.com>
	<4BFDC44D.9070008@silveregg.co.jp> <4BFE7F4A.7010805@enthought.com>
	<AANLkTimPOTVZuH8lWcekGUe1j4QFXKq37Qft_7-9ScaF@mail.gmail.com>
	<4BFEEEB3.9050602@enthought.com>
	<AANLkTikQhRGqBA1uge9_K1cTEpqxxCN4V6b27xjdv9dm@mail.gmail.com>
	<AANLkTikKa6sXINwQZ1zoc9OZpFw4eG1I9AKzhhfdc9gi@mail.gmail.com>
	<AANLkTik62PCNl3ktYzApPXz7vKzoYzEmdStSJVckcnJQ@mail.gmail.com>
	<AANLkTimNmEhhe0dGUH8D4fxirTol_C2FNhwSJJ5CRju1@mail.gmail.com>
	<AANLkTikpjAipZIvsBCvhQvTQb1eLiGhcCA0ER3I0VNjK@mail.gmail.com>
	<AANLkTimavIEqRsec_RSWjCz1MrpZUtZCPKpPhExEliNM@mail.gmail.com>
	<AANLkTinZ7q2TCSLjJqiZEj7BnJYj8fv_7m-o7gLt98rJ@mail.gmail.com>
	<AANLkTil2tp2XKzyK07xnDoZFvkUY3zTgrKqN_GQ_6BU5@mail.gmail.com>
Message-ID: <AANLkTim16YnPUS8t3rSUIh3L89xK6o6yLf67ODtenhVB@mail.gmail.com>

Hi,

> I try very hard to write very precisely in plain language
> and avoid rhetorical devices.

Yes - I know - and it's an aspect of your emails that I enjoy and have
learned from - thank you.

See you,

Matthew


From matthew.brett at gmail.com  Sat May 29 17:51:55 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 May 2010 14:51:55 -0700
Subject: [SciPy-Dev] scipy.io matlab reader - things to change before
	0.8.0
In-Reply-To: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
References: <AANLkTin88B7PDVTFaKiGcbgV08nu72cIitAhp5gWxw3i@mail.gmail.com>
Message-ID: <AANLkTilv3Lq6bECPvn9y9Hxtd6uW7WDdTRvJ1OZhchf8@mail.gmail.com>

Hi,

> scipy.io.loadmat should _default_ to struct_as_record = True

Done.

> There's a FutureWarning for:
>
> scipy.io.loadmat('somefile') # when looking for somefile.mat
>
> I propose to upgrade to a DeprecationWarning

Done

> There are DeprecationWarnings for:
>
> scipy.io.loadmat('somefile.mat', basename='something')

All references to basename removed, raises TypeError if used.

> scipy.io.savemat('somefile.mat', a_3D_array, format='4') # currently
> silently saves to 2D matrix
>
> I propose to upgrade to an Exception in both cases.

I've left this one because it wasn't in 0.7.0...

Cheers,

Matthew


From warren.weckesser at enthought.com  Sat May 29 20:58:38 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Sat, 29 May 2010 19:58:38 -0500
Subject: [SciPy-Dev] Checkin checklist
Message-ID: <4C01B83E.7040108@enthought.com>

Here's a first shot at a checklist to use when working on scipy.  
Something like this should be in the development section of the wiki.  
What do you think?

Checkin checklist:

* Have you created tests for the new functionality, and have you run
  all the module's tests to ensure you haven't broken something else?

* Do all the affected classes, methods, and functions have accurate
  docstrings that conform to the scipy documentation standard? 

* Have you updated the module-level documentation?
  There are (usually) two relevant files:
  * scipy/some_package/info.py
  * doc/source/some_package.rst

* Have you updated the release notes? (doc/release/0.8.0-notes.rst)
  Any API changes (new stuff, changed stuff, deprecations, etc)
  should be noted in the release notes.

* If the changes affect a tutorial, have you updated the tutorial?
  The tutorials are in doc/source/tutorial.



From matthew.brett at gmail.com  Sat May 29 21:29:19 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Sat, 29 May 2010 18:29:19 -0700
Subject: [SciPy-Dev] Checkin checklist
In-Reply-To: <4C01B83E.7040108@enthought.com>
References: <4C01B83E.7040108@enthought.com>
Message-ID: <AANLkTimtfWUqFJNNU2LuJ-Wt67RF7_JiaDwiHg5kI14M@mail.gmail.com>

Hi,

On Sat, May 29, 2010 at 5:58 PM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> Here's a first shot at a checklist to use when working on scipy.
> Something like this should be in the development section of the wiki.
> What do you think?
>
> Checkin checklist:
>
> * Have you created tests for the new functionality, and have you run
> ?all the module's tests to ensure you haven't broken something else?
>
> * Do all the affected classes, methods, and functions have accurate
> ?docstrings that conform to the scipy documentation standard?
>
> * Have you updated the module-level documentation?
> ?There are (usually) two relevant files:
> ?* scipy/some_package/info.py
> ?* doc/source/some_package.rst
>
> * Have you updated the release notes? (doc/release/0.8.0-notes.rst)
> ?Any API changes (new stuff, changed stuff, deprecations, etc)
> ?should be noted in the release notes.
>
> * If the changes affect a tutorial, have you updated the tutorial?
> ?The tutorials are in doc/source/tutorial.

Ouch - good call.  These sound like a very reasonable list to me.

Have we got anything like a sub-package maintainers list?   Obviously
I'm good for at least scipy.io.matlab...

Thanks a lot,

Matthew


From d.l.goldsmith at gmail.com  Sat May 29 22:08:10 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sat, 29 May 2010 19:08:10 -0700
Subject: [SciPy-Dev] Checkin checklist
In-Reply-To: <AANLkTimtfWUqFJNNU2LuJ-Wt67RF7_JiaDwiHg5kI14M@mail.gmail.com>
References: <4C01B83E.7040108@enthought.com>
	<AANLkTimtfWUqFJNNU2LuJ-Wt67RF7_JiaDwiHg5kI14M@mail.gmail.com>
Message-ID: <AANLkTilPkTnnUxMKuMJnNcNCgdKkdNP_PFUEPfVD4-gS@mail.gmail.com>

+1  Only one comment: the docstring Standard says this about the Examples
section:

"...While optional, this section is very strongly encouraged."

IMHO, this is too weak when the object in question is a function, so I would
"very strongly encourage" you to add to Item 2 something to the effect of:

"...have accurate docstrings that conform to the scipy documentation
standard, including example(s) if the object is a function."

I'd really like to see every function have at least one example. :-)

DG

On Sat, May 29, 2010 at 6:29 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Sat, May 29, 2010 at 5:58 PM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
> > Here's a first shot at a checklist to use when working on scipy.
> > Something like this should be in the development section of the wiki.
> > What do you think?
> >
> > Checkin checklist:
> >
> > * Have you created tests for the new functionality, and have you run
> >  all the module's tests to ensure you haven't broken something else?
> >
> > * Do all the affected classes, methods, and functions have accurate
> >  docstrings that conform to the scipy documentation standard?
> >
> > * Have you updated the module-level documentation?
> >  There are (usually) two relevant files:
> >  * scipy/some_package/info.py
> >  * doc/source/some_package.rst
> >
> > * Have you updated the release notes? (doc/release/0.8.0-notes.rst)
> >  Any API changes (new stuff, changed stuff, deprecations, etc)
> >  should be noted in the release notes.
> >
> > * If the changes affect a tutorial, have you updated the tutorial?
> >  The tutorials are in doc/source/tutorial.
>
> Ouch - good call.  These sound like a very reasonable list to me.
>
> Have we got anything like a sub-package maintainers list?   Obviously
> I'm good for at least scipy.io.matlab...
>
> Thanks a lot,
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100529/16014ab8/attachment.html>

From ralf.gommers at googlemail.com  Sun May 30 08:49:22 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 30 May 2010 20:49:22 +0800
Subject: [SciPy-Dev] Do we have docstring Standards for objects "above"
	classes/functions?
In-Reply-To: <AANLkTil_o6HNirHoK1spieYzZLXRpXR5QYxRRlyKqcSy@mail.gmail.com>
References: <AANLkTil_o6HNirHoK1spieYzZLXRpXR5QYxRRlyKqcSy@mail.gmail.com>
Message-ID: <AANLkTimq6NQgq9jUlB45-VxeSooRcDm0JriyGlB1pbzE@mail.gmail.com>

On Sat, May 29, 2010 at 1:13 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> i.e., modules, sub-packages, packages (have I forgotten anything?)
> Semi-rhetorical follow-up: should we develop/promulgate some?  (I don't
> _think_ there's presently any consistency in this regard in SciPy; I _hope_
> there is in NumPy, though I wouldn't stake my life on it.)
>
> http://projects.scipy.org/numpy/ticket/1280
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/d9cbdee9/attachment.html>

From ralf.gommers at googlemail.com  Sun May 30 09:33:20 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 30 May 2010 21:33:20 +0800
Subject: [SciPy-Dev] trunk open for 0.9 development
Message-ID: <AANLkTikcmDPfkngqBjtEl6y9lM_WwBUrcCXHlJAJZcDy@mail.gmail.com>

Hi all,

The 0.8.x branch is created, trunk is open for 0.9. I'm looking forward to
py3k compatibility!

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/88f7fa0d/attachment.html>

From ralf.gommers at googlemail.com  Sun May 30 10:11:33 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 30 May 2010 22:11:33 +0800
Subject: [SciPy-Dev] Lapack alignment test in linalg failing
Message-ID: <AANLkTilDmp9bF2StL_tbD41kh2GK_w3zqEc5je1-YR-q@mail.gmail.com>

Hi Anne,

Will you be able to resolve this issue before the first release candidate
for 0.8.0 comes out (planned on June 11th)? If not, can you please mark it
as knownfail in 0.8.x?

Thanks,
Ralf


[below is copy of thread from April 13]

Anne Archibald wrote:
> On 12 April 2010 16:34, Warren Weckesser <warren.weckesser <at> enthought.com> wrote:

>
>> Anne Archibald wrote:
>>
>>> On 12 April 2010 12:22, Warren Weckesser <warren.weckesser <at> enthought.com> wrote:
>>>

>>>
>>>> I created a ticket: http://projects.scipy.org/scipy/ticket/1152
>>>>
>>>> If any of the original authors or editors of the code that tests

>>>> misaligned arrays are still around, some feedback would be appreciated,
>>>> especially about why the misalignment is being done twice.  I'm not sure
>>>> if that is intentional.

>>>>
>>>>
>>> That code is my fault, and it's a mess. I think the correct way to
>>> handle this is to catch the "NaNs/Infs present" exception, or possibly

>>> to edit the misaligned arrays to remove any NaNs/Infs. Unfortunately
>>> the bug this was attempting to tickle is deep in the bowels of ATLAS,
>>> and is very difficult to trigger correctly; in particular, an identity

>>> matrix does not trigger the bug. This is the reason S is misaligned
>>> twice: it takes that kind of bizarre data to trigger the bug. Since
>>> the symptom of the bug is a segfault, raising a "no NaNs" error

>>> qualifies as a pass (though I'm a little surprised you got any NaNs -
>>> what platform are you using?)
>>>
>>>
>>>
>> Using scipy 0.8.0 r6120 or later, I get the same error on Mac OSX, Linux

>> (RH 64 bit), and Windows XP.
>>
>
> That is disturbing. I'll try to take a look at this version when I get
> home and see if I trigger the bug.
>
>
>> Does the test really need to reuse the output of the first call of

>> solve() as the input to the second call? That is, does it really need
>> overwrite enabled?  If so, then catching the exception and calling that
>> a "pass" doesn't seem right, because that prevents the underlying lapack

>> routine from being called the second time.
>>
>
> The bug is only triggered when overwrite is enabled, but the code does
> not actually reuse any argument arrays.

The arrays are reused in check_lapack_misaligned(); this is what is

causing the error.  When func=solve, args=(S,b) and
kwargs={overwrite_a:True, overwrite_b:True}, and when i=0, 'solve' is
called once on line 1071 (referring to rev 6321), and again on line
1074. In the second call, a[i] is a transposed view of the same data as

the previous call, and b is the same array.  The error occurs when the
first call results in NaNs in the arrays.

Warren

>  I should at least rearrange
> the code so that the different offsets are different tests (so that

> all get run even if one fails), but I had in mind catching the
> exception on one call of the LAPACK function but then passing on to
> the others.
>
> Anne
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/5fb5203e/attachment.html>

From ralf.gommers at googlemail.com  Sun May 30 10:25:10 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Sun, 30 May 2010 22:25:10 +0800
Subject: [SciPy-Dev] lambertw test failure
Message-ID: <AANLkTilEfz-9dkF78MN_S0loTZuQf-M3H3Ijmwb3nXId@mail.gmail.com>

This test has been failing for a long time. Does anyone know what's going
on, and can it be fixed in the next ten days or so?

======================================================================
FAIL: test_lambertw.test_values
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
line 183, in runTest
    self.test(*self.arg)
  File "/Users/rgommers/Code/scipy/scipy/special/tests/test_lambertw.py",
line 80, in test_values
    FuncData(w, data, (0,1), 2, rtol=1e-10, atol=1e-13).check()
  File "/Users/rgommers/Code/scipy/scipy/special/tests/testutils.py", line
187, in check
    assert False, "\n".join(msg)
AssertionError:
Max |adiff|: 2.5797
Max |rdiff|: 3.81511
Bad results for the following points (in output 0):
(-0.44800000000000001+0.40000000000000002j)                              0j
=> (-1.2370928928166736-1.6588828572971359j) !=
(-0.11855133765652383+0.66570534313583418j)  (rdiff
3.8151122286225245)

There's also a ticket regarding the lambertw docstring:
http://projects.scipy.org/scipy/ticket/1148

Thanks,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/c0f1c3a4/attachment.html>

From jsseabold at gmail.com  Sun May 30 10:46:43 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Sun, 30 May 2010 10:46:43 -0400
Subject: [SciPy-Dev] line endings in test failures?
In-Reply-To: <AANLkTil_9yezX7ZX0fskVLquIQ0Xvtj3KPzdzMAQG-cp@mail.gmail.com>
References: <AANLkTim2bo9061V8QOjTLNg0LOQqQgH1UWcpAnRSaqWI@mail.gmail.com> 
	<ht3a87$1ka$1@dough.gmane.org>
	<AANLkTimPrYmcR5e7VMSiJnPW8CZpWP0vLElUdPD46qY1@mail.gmail.com> 
	<ht3pd1$23q$1@dough.gmane.org>
	<AANLkTil_9yezX7ZX0fskVLquIQ0Xvtj3KPzdzMAQG-cp@mail.gmail.com>
Message-ID: <AANLkTimZeMHMzGAgodIIc77srumriNSZJT9OJqSIqRfN@mail.gmail.com>

On Thu, May 20, 2010 at 1:09 PM, Skipper Seabold <jsseabold at gmail.com> wrote:
> On Thu, May 20, 2010 at 12:52 PM, Pauli Virtanen <pav at iki.fi> wrote:
>> Thu, 20 May 2010 10:44:34 -0400, Skipper Seabold wrote:
>> [clip]
>>> Ah, so it is. ?Just out of curiosity, why did you turn this always on?
>>> ?I don't see what assert introspection adds in a case like this. ?Is
>>> it possible to make it optional but a default keyword to
>>> NoseTester.test's extra_argv?
>>
>> There were some tests that only did
>>
>> ? ? ? ?assert (something)
>>
>> and it was useful to see what the something was on the buildbot, when
>> they were failing. I don't think this can be turned on on a per-test
>> basis.
>>
>> Anyway, if it seems too disturbing, I guess it can be turned back off.
>>
>
> It really doesn't matter to me, if it's helpful to you, I just had to
> sift through a lot of extra noise refactoring some tests. ?We use a
> monkey-patched version of NoseTester for statsmodels and if you apply
> the following diff (numpy/tesing/nosetester.py), it would allow me to
> get around the --detailed-errors. ?I don't think it changes the new
> default behavior for numpy, but makes it optional.
>
>
> Index: nosetester.py
> ===================================================================
> --- nosetester.py ? ? ? (revision 8417)
> +++ nosetester.py ? ? ? (working copy)
> @@ -230,9 +230,6 @@
> ? ? ? ? ? ? argv+=['--cover-package=%s' % self.package_name, '--with-coverage',
> ? ? ? ? ? ? ? ? ? ?'--cover-tests', '--cover-inclusive', '--cover-erase']
>
> - ? ? ? ?# enable assert introspection
> - ? ? ? ?argv += ['--detailed-errors']
> -
> ? ? ? ? # bypass these samples under distutils
> ? ? ? ? argv += ['--exclude','f2py_ext']
> ? ? ? ? argv += ['--exclude','f2py_f90_ext']
> @@ -249,8 +246,8 @@
> ? ? ? ? plugins += [p() for p in nose.plugins.builtin.plugins]
> ? ? ? ? return argv, plugins
>
> - ? ?def test(self, label='fast', verbose=1, extra_argv=None, doctests=False,
> - ? ? ? ? ? ? coverage=False):
> + ? ?def test(self, label='fast', verbose=1, extra_argv=['--detailed-errors'],
> + ? ? ? ? ? ?doctests=False, coverage=False):
> ? ? ? ? """
> ? ? ? ? Run tests for module using nose.
>

I filed a ticket with a patch, so this doesn't get forgotten.

http://projects.scipy.org/numpy/ticket/1498

Skipper
>


From fredrik.johansson at gmail.com  Sun May 30 11:18:20 2010
From: fredrik.johansson at gmail.com (Fredrik Johansson)
Date: Sun, 30 May 2010 17:18:20 +0200
Subject: [SciPy-Dev] lambertw test failure
In-Reply-To: <AANLkTilEfz-9dkF78MN_S0loTZuQf-M3H3Ijmwb3nXId@mail.gmail.com>
References: <AANLkTilEfz-9dkF78MN_S0loTZuQf-M3H3Ijmwb3nXId@mail.gmail.com>
Message-ID: <AANLkTikRW8mf_RKiRHt2vmlNwPURNdvwd0WASIbxTiz0@mail.gmail.com>

On Sun, May 30, 2010 at 4:25 PM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

> This test has been failing for a long time. Does anyone know what's going
> on, and can it be fixed in the next ten days or so?
>
> ======================================================================
> FAIL: test_lambertw.test_values
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/nose-0.11.1-py2.6.egg/nose/case.py",
> line 183, in runTest
>     self.test(*self.arg)
>   File "/Users/rgommers/Code/scipy/scipy/special/tests/test_lambertw.py",
> line 80, in test_values
>     FuncData(w, data, (0,1), 2, rtol=1e-10, atol=1e-13).check()
>   File "/Users/rgommers/Code/scipy/scipy/special/tests/testutils.py", line
> 187, in check
>     assert False, "\n".join(msg)
> AssertionError:
> Max |adiff|: 2.5797
> Max |rdiff|: 3.81511
> Bad results for the following points (in output 0):
> (-0.44800000000000001+0.40000000000000002j)                              0j
> => (-1.2370928928166736-1.6588828572971359j) !=
> (-0.11855133765652383+0.66570534313583418j)  (rdiff
> 3.8151122286225245)
>
> There's also a ticket regarding the lambertw docstring:
> http://projects.scipy.org/scipy/ticket/1148
>
> Thanks,
> Ralf
>

I think two lines were left out when the mpmath code was transliterated to
Cython. In lambertw.pyx, I believe

        if zabs(z+0.5) < 0.1:
            if z.imag > 0:
                w = 0.7 + 0.7j
            else:
                w = 0.7 - 0.7j

needs to be

        if zabs(z+0.5) < 0.1:
            if z.imag > 0:
                w = 0.7 + 0.7j
            else:
                w = 0.7 - 0.7j
        else:
            w = z

Fredrik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/08533b07/attachment.html>

From d.l.goldsmith at gmail.com  Sun May 30 12:32:03 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Sun, 30 May 2010 09:32:03 -0700
Subject: [SciPy-Dev] Do we have docstring Standards for objects "above"
	classes/functions?
In-Reply-To: <AANLkTimq6NQgq9jUlB45-VxeSooRcDm0JriyGlB1pbzE@mail.gmail.com>
References: <AANLkTil_o6HNirHoK1spieYzZLXRpXR5QYxRRlyKqcSy@mail.gmail.com>
	<AANLkTimq6NQgq9jUlB45-VxeSooRcDm0JriyGlB1pbzE@mail.gmail.com>
Message-ID: <AANLkTinwkvwAbCj1MG7u06M4eU4t4ihvlbEDWiCtnOj-@mail.gmail.com>

On Sun, May 30, 2010 at 5:49 AM, Ralf Gommers
<ralf.gommers at googlemail.com>wrote:

>
>
> On Sat, May 29, 2010 at 1:13 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:
>
>> i.e., modules, sub-packages, packages (have I forgotten anything?)
>> Semi-rhetorical follow-up: should we develop/promulgate some?  (I don't
>> _think_ there's presently any consistency in this regard in SciPy; I _hope_
>> there is in NumPy, though I wouldn't stake my life on it.)
>>
>> http://projects.scipy.org/numpy/ticket/1280
>

Thanks Ralf!

All: Charles H. and I have (separately) added comments to this ticket that
invite community input; for your convenience, I'll reproduce them here:

CH: "I think routine listings needs to be expanded a bit. There are three
things that are likely to be found in modules that aren't in functions:
classes, functions, and constants. I'm not sure how these should be handled,
but we need a policy and an example."

DG: "Can/should we expand this to 'doc standard for modules, sub-packages,
and packages,' [the current ticket title stops at modules] or are there
things about the latter two which make them require their own standard(s)?"

If you have an opinion/input on either of these issues, please contribute
such as a ticket comment by visiting the link above.  Under the auspices of
the Summer Marathon, lets try to close this ticket within the week.

Thanks!

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100530/d300cb25/attachment.html>

From pav at iki.fi  Mon May 31 04:46:04 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 31 May 2010 08:46:04 +0000 (UTC)
Subject: [SciPy-Dev] lambertw test failure
References: <AANLkTilEfz-9dkF78MN_S0loTZuQf-M3H3Ijmwb3nXId@mail.gmail.com>
	<AANLkTikRW8mf_RKiRHt2vmlNwPURNdvwd0WASIbxTiz0@mail.gmail.com>
Message-ID: <htvt0c$1ha$1@dough.gmane.org>

Hi,

Sun, 30 May 2010 17:18:20 +0200, Fredrik Johansson wrote:
> I think two lines were left out when the mpmath code was transliterated
> to Cython. In lambertw.pyx, I believe
[clip]
> needs to be
[clip]

Thanks! Should be fixed in trunk and 0.8.x

	Pauli



From pav at iki.fi  Mon May 31 05:27:54 2010
From: pav at iki.fi (Pauli Virtanen)
Date: Mon, 31 May 2010 09:27:54 +0000 (UTC)
Subject: [SciPy-Dev] Invalid syntax on Python < 2.6 in scipy.stats
Message-ID: <htvveq$j75$1@dough.gmane.org>

There's some invalid syntax in Scipy trunk and 0.8.x branches that would 
need to be fixed:

http://projects.scipy.org/scipy/ticket/1186



From josef.pktd at gmail.com  Mon May 31 10:16:36 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 31 May 2010 10:16:36 -0400
Subject: [SciPy-Dev] scipy.stats
Message-ID: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>

Since Travis seems to want to take back control of scipy.stats, I am
considering my role as inofficial maintainer as ended.

I would have appreciated his help almost 3 years ago, when I started
to learn numpy, scipy, and started to submit patches for
scipy.stats.distributions.

But by now, I have pretty strong opinions about statistics in python,
after almost  three years, I'm a bit tired of cleaning up the mess of
others (and want to clean up my own mess), and there are obviously big
philosophical differences for the development process between me and
Travis (no discussion, no review, no tests).
http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests

Watching the scipy changelog and checking any function that Travis
quietly commits is no fun (see mailing list for the introduction of
curve_fit or ask Stefan).

I said early on that I would like to trust the results that
scipy.stats produces (although I don't find the mailing list thread
any more).

I considered scipy to go into a stable direction like Python is,
kitchen sink for scientific programming, which might be slow-moving
but with high standards, and not a sandbox.

Details are at http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html

After my initial scipy.stats.distributions cleanup, test coverage was
at 91%, I have no idea where it is after this weekend.

This is more about the process then the content, distributions was
Travis's baby (although unfinished), and most of his changes are very
good, but I don't want to look for the 5-10% (?) typos anymore.

Cheers,

Josef


From charlesr.harris at gmail.com  Mon May 31 10:23:06 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 08:23:06 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
Message-ID: <AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>

On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:

> Since Travis seems to want to take back control of scipy.stats, I am
> considering my role as inofficial maintainer as ended.
>
> I would have appreciated his help almost 3 years ago, when I started
> to learn numpy, scipy, and started to submit patches for
> scipy.stats.distributions.
>
> But by now, I have pretty strong opinions about statistics in python,
> after almost  three years, I'm a bit tired of cleaning up the mess of
> others (and want to clean up my own mess), and there are obviously big
> philosophical differences for the development process between me and
> Travis (no discussion, no review, no tests).
> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>
> Watching the scipy changelog and checking any function that Travis
> quietly commits is no fun (see mailing list for the introduction of
> curve_fit or ask Stefan).
>
> I said early on that I would like to trust the results that
> scipy.stats produces (although I don't find the mailing list thread
> any more).
>
> I considered scipy to go into a stable direction like Python is,
> kitchen sink for scientific programming, which might be slow-moving
> but with high standards, and not a sandbox.
>
> Details are at
> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>
> After my initial scipy.stats.distributions cleanup, test coverage was
> at 91%, I have no idea where it is after this weekend.
>
> This is more about the process then the content, distributions was
> Travis's baby (although unfinished), and most of his changes are very
> good, but I don't want to look for the 5-10% (?) typos anymore.
>
>
Ah Josef, there are easier ways to lodge complaints than resignation ;) I
agree that it was rude of Travis to make those changes without running them
through the list, and he does tend to toss stuff in that others have to
clean up, the same with c-code. But maybe we can manage to get him
housebroken without all moving out.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/20dfcde4/attachment.html>

From josef.pktd at gmail.com  Mon May 31 10:28:05 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 31 May 2010 10:28:05 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
Message-ID: <AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>

On Mon, May 31, 2010 at 10:23 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>>
>> Since Travis seems to want to take back control of scipy.stats, I am
>> considering my role as inofficial maintainer as ended.
>>
>> I would have appreciated his help almost 3 years ago, when I started
>> to learn numpy, scipy, and started to submit patches for
>> scipy.stats.distributions.
>>
>> But by now, I have pretty strong opinions about statistics in python,
>> after almost ?three years, I'm a bit tired of cleaning up the mess of
>> others (and want to clean up my own mess), and there are obviously big
>> philosophical differences for the development process between me and
>> Travis (no discussion, no review, no tests).
>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>
>> Watching the scipy changelog and checking any function that Travis
>> quietly commits is no fun (see mailing list for the introduction of
>> curve_fit or ask Stefan).
>>
>> I said early on that I would like to trust the results that
>> scipy.stats produces (although I don't find the mailing list thread
>> any more).
>>
>> I considered scipy to go into a stable direction like Python is,
>> kitchen sink for scientific programming, which might be slow-moving
>> but with high standards, and not a sandbox.
>>
>> Details are at
>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>
>> After my initial scipy.stats.distributions cleanup, test coverage was
>> at 91%, I have no idea where it is after this weekend.
>>
>> This is more about the process then the content, distributions was
>> Travis's baby (although unfinished), and most of his changes are very
>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>
>
> Ah Josef, there are easier ways to lodge complaints than resignation ;) I
> agree that it was rude of Travis to make those changes without running them
> through the list, and he does tend to toss stuff in that others have to
> clean up, the same with c-code. But maybe we can manage to get him
> housebroken without all moving out.

I think the discussion with him occurred already several times on the lists.

Josef


> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From charlesr.harris at gmail.com  Mon May 31 10:38:28 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 08:38:28 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
Message-ID: <AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>

On Mon, May 31, 2010 at 8:23 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
>
> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>
>> Since Travis seems to want to take back control of scipy.stats, I am
>> considering my role as inofficial maintainer as ended.
>>
>> I would have appreciated his help almost 3 years ago, when I started
>> to learn numpy, scipy, and started to submit patches for
>> scipy.stats.distributions.
>>
>> But by now, I have pretty strong opinions about statistics in python,
>> after almost  three years, I'm a bit tired of cleaning up the mess of
>> others (and want to clean up my own mess), and there are obviously big
>> philosophical differences for the development process between me and
>> Travis (no discussion, no review, no tests).
>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>
>> Watching the scipy changelog and checking any function that Travis
>> quietly commits is no fun (see mailing list for the introduction of
>> curve_fit or ask Stefan).
>>
>> I said early on that I would like to trust the results that
>> scipy.stats produces (although I don't find the mailing list thread
>> any more).
>>
>> I considered scipy to go into a stable direction like Python is,
>> kitchen sink for scientific programming, which might be slow-moving
>> but with high standards, and not a sandbox.
>>
>> Details are at
>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>
>> After my initial scipy.stats.distributions cleanup, test coverage was
>> at 91%, I have no idea where it is after this weekend.
>>
>> This is more about the process then the content, distributions was
>> Travis's baby (although unfinished), and most of his changes are very
>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>
>>
> Ah Josef, there are easier ways to lodge complaints than resignation ;) I
> agree that it was rude of Travis to make those changes without running them
> through the list, and he does tend to toss stuff in that others have to
> clean up, the same with c-code. But maybe we can manage to get him
> housebroken without all moving out.
>
>
I think a policy of mandatory review will solve these sorts of problems, and
that is probably a good argument for moving to github where review is much
easier. On stats, we probably need an additional policy of rigorous testing
to make sure that things are working right, the stat tests are more
difficult by their very nature. I think Travis is amenable to such
processes, but we do need to start a discussion. If you do feel strongly
about the recent changes maybe they can be reverted and added back in after
review.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/94d8f42d/attachment.html>

From charlesr.harris at gmail.com  Mon May 31 10:43:49 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 08:43:49 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
Message-ID: <AANLkTik6VK1qJC9h3END9pGHHdOOQ197WHEf_GSKqn5x@mail.gmail.com>

On Mon, May 31, 2010 at 8:28 AM, <josef.pktd at gmail.com> wrote:

> On Mon, May 31, 2010 at 10:23 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
> >>
> >> Since Travis seems to want to take back control of scipy.stats, I am
> >> considering my role as inofficial maintainer as ended.
> >>
> >> I would have appreciated his help almost 3 years ago, when I started
> >> to learn numpy, scipy, and started to submit patches for
> >> scipy.stats.distributions.
> >>
> >> But by now, I have pretty strong opinions about statistics in python,
> >> after almost  three years, I'm a bit tired of cleaning up the mess of
> >> others (and want to clean up my own mess), and there are obviously big
> >> philosophical differences for the development process between me and
> >> Travis (no discussion, no review, no tests).
> >> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
> >>
> >> Watching the scipy changelog and checking any function that Travis
> >> quietly commits is no fun (see mailing list for the introduction of
> >> curve_fit or ask Stefan).
> >>
> >> I said early on that I would like to trust the results that
> >> scipy.stats produces (although I don't find the mailing list thread
> >> any more).
> >>
> >> I considered scipy to go into a stable direction like Python is,
> >> kitchen sink for scientific programming, which might be slow-moving
> >> but with high standards, and not a sandbox.
> >>
> >> Details are at
> >> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
> >>
> >> After my initial scipy.stats.distributions cleanup, test coverage was
> >> at 91%, I have no idea where it is after this weekend.
> >>
> >> This is more about the process then the content, distributions was
> >> Travis's baby (although unfinished), and most of his changes are very
> >> good, but I don't want to look for the 5-10% (?) typos anymore.
> >>
> >
> > Ah Josef, there are easier ways to lodge complaints than resignation ;) I
> > agree that it was rude of Travis to make those changes without running
> them
> > through the list, and he does tend to toss stuff in that others have to
> > clean up, the same with c-code. But maybe we can manage to get him
> > housebroken without all moving out.
>
> I think the discussion with him occurred already several times on the
> lists.
>
>
But he forgets. In any case, I feel that you are currently the essential
person in the stats area because of your hard work, expertise, and planning,
and we need to fix things up so that you are happy. Make some suggestions.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/4eb2de96/attachment.html>

From ce at vejnar.eu  Mon May 31 10:55:53 2010
From: ce at vejnar.eu (Charles Vejnar)
Date: Mon, 31 May 2010 16:55:53 +0200
Subject: [SciPy-Dev] Scipy archive on PyPI
Message-ID: <201005311655.53741.ce@vejnar.eu>

Hi,

I was trying to install Scipy with easy_install and it seems that downloading 
from Sourceforge is no longer possible (Sourceforge no longer gives a direct 
link to the .tar.gz file) which makes the install fail.

Would it be possible to always upload the latest Scipy tarball to PyPI ?

Thanks

Charles




From josef.pktd at gmail.com  Mon May 31 11:14:29 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 31 May 2010 11:14:29 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTik6VK1qJC9h3END9pGHHdOOQ197WHEf_GSKqn5x@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
	<AANLkTik6VK1qJC9h3END9pGHHdOOQ197WHEf_GSKqn5x@mail.gmail.com>
Message-ID: <AANLkTikXZskHHj-ib6Cg8kb0XD0_i5RfmQrR2gupaDwU@mail.gmail.com>

On Mon, May 31, 2010 at 10:43 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, May 31, 2010 at 8:28 AM, <josef.pktd at gmail.com> wrote:
>>
>> On Mon, May 31, 2010 at 10:23 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> > On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>> >>
>> >> Since Travis seems to want to take back control of scipy.stats, I am
>> >> considering my role as inofficial maintainer as ended.
>> >>
>> >> I would have appreciated his help almost 3 years ago, when I started
>> >> to learn numpy, scipy, and started to submit patches for
>> >> scipy.stats.distributions.
>> >>
>> >> But by now, I have pretty strong opinions about statistics in python,
>> >> after almost ?three years, I'm a bit tired of cleaning up the mess of
>> >> others (and want to clean up my own mess), and there are obviously big
>> >> philosophical differences for the development process between me and
>> >> Travis (no discussion, no review, no tests).
>> >> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>> >>
>> >> Watching the scipy changelog and checking any function that Travis
>> >> quietly commits is no fun (see mailing list for the introduction of
>> >> curve_fit or ask Stefan).
>> >>
>> >> I said early on that I would like to trust the results that
>> >> scipy.stats produces (although I don't find the mailing list thread
>> >> any more).
>> >>
>> >> I considered scipy to go into a stable direction like Python is,
>> >> kitchen sink for scientific programming, which might be slow-moving
>> >> but with high standards, and not a sandbox.
>> >>
>> >> Details are at
>> >> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>> >>
>> >> After my initial scipy.stats.distributions cleanup, test coverage was
>> >> at 91%, I have no idea where it is after this weekend.
>> >>
>> >> This is more about the process then the content, distributions was
>> >> Travis's baby (although unfinished), and most of his changes are very
>> >> good, but I don't want to look for the 5-10% (?) typos anymore.
>> >>
>> >
>> > Ah Josef, there are easier ways to lodge complaints than resignation ;)
>> > I
>> > agree that it was rude of Travis to make those changes without running
>> > them
>> > through the list, and he does tend to toss stuff in that others have to
>> > clean up, the same with c-code. But maybe we can manage to get him
>> > housebroken without all moving out.
>>
>> I think the discussion with him occurred already several times on the
>> lists.
>>
>
> But he forgets. In any case, I feel that you are currently the essential
> person in the stats area because of your hard work, expertise, and planning,
> and we need to fix things up so that you are happy. Make some suggestions.

My approach has been to block any untested, non-trivial changes, and
to review and test changes by others, so we don't increase the amount
of "technological debt".

The second part is testing and verification of existing functions
(finish the statistical review which has been lingering for several
years), which is slow going because I'm almost the only one doing it.

The third part is develop enhancements and prepare for a consistent
refactoring of "statistics in python" in a sandbox outside of scipy.
(Here, I admit I have a small conflict of interest getting things
quickly into scipy, because I'm more interested in "Statistics in
Python" than statistics in scipy.)

I have been a bit slow working on scipy trunk in the last year because
I worked more on statsmodels, and I didn't have always the time (or
didn't feel like) keeping up with recompiling numpy/scipy.

(My alternative is to develop pythonstats completely outside of
scipy.stats, maintaining a smaller set of verified functions and just
ignore scipy.stats for now.)

Josef

>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From ralf.gommers at googlemail.com  Mon May 31 11:15:03 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 31 May 2010 23:15:03 +0800
Subject: [SciPy-Dev] Scipy archive on PyPI
In-Reply-To: <201005311655.53741.ce@vejnar.eu>
References: <201005311655.53741.ce@vejnar.eu>
Message-ID: <AANLkTikch7lzbB_IzHHn4a-NjaRHJDmE1PHmV5fv6wP_@mail.gmail.com>

On Mon, May 31, 2010 at 10:55 PM, Charles Vejnar <ce at vejnar.eu> wrote:

> Hi,
>
> I was trying to install Scipy with easy_install and it seems that
> downloading
> from Sourceforge is no longer possible (Sourceforge no longer gives a
> direct
> link to the .tar.gz file) which makes the install fail.
>
> Would it be possible to always upload the latest Scipy tarball to PyPI ?
>
> It's possible, but because that encourages the use of easy_install/pip it
would probably give more problems than that it helps. Just today there was a
thread on numpy-discussion about pip failing and standard "python setup.py
install" fixing the problem. easy_install is just as problematic as pip, if
not more so.

People should really be encouraged to install from binaries, and otherwise
follow the build instructions for their platform.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/2b4aca33/attachment.html>

From aisaac at american.edu  Mon May 31 11:21:41 2010
From: aisaac at american.edu (Alan G Isaac)
Date: Mon, 31 May 2010 11:21:41 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
Message-ID: <4C03D405.7010703@american.edu>

On 5/31/2010 10:16 AM, josef.pktd at gmail.com wrote:
> Since Travis seems to want to take back control of scipy.stats, I am
> considering my role as inofficial maintainer as ended.

Perhaps offering to make your role more official
and placing conditions on it would be more productive.

Cheers,
Alan



From ralf.gommers at googlemail.com  Mon May 31 11:24:22 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 31 May 2010 23:24:22 +0800
Subject: [SciPy-Dev] updated 0.8.0 release schedule
Message-ID: <AANLkTimBp1DuutuJcdLlUSGDYFu0Lc2GEWSStnf1_H-d@mail.gmail.com>

Hi all,

Beta 1 for 0.8.0 was supposed to be available today, and I built some
binaries before realizing that scipy.stats is currently not importable on
python 2.4/2.5. On top of that I will be traveling, probably without
internet access, from 8-14 June. So here's a revised release schedule:

03/06: 0.8.0 beta 1
17/06: 0.8.0 release candidate 1
24/06: 0.8.0 release

I hope that doesn't inconvenience anyone too much.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/c9ad8ed6/attachment.html>

From jsseabold at gmail.com  Mon May 31 11:32:24 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Mon, 31 May 2010 11:32:24 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com> 
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com> 
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
Message-ID: <AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>

On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
>>
>>
>> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>>>
>>> Since Travis seems to want to take back control of scipy.stats, I am
>>> considering my role as inofficial maintainer as ended.
>>>
>>> I would have appreciated his help almost 3 years ago, when I started
>>> to learn numpy, scipy, and started to submit patches for
>>> scipy.stats.distributions.
>>>
>>> But by now, I have pretty strong opinions about statistics in python,
>>> after almost ?three years, I'm a bit tired of cleaning up the mess of
>>> others (and want to clean up my own mess), and there are obviously big
>>> philosophical differences for the development process between me and
>>> Travis (no discussion, no review, no tests).
>>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>>
>>> Watching the scipy changelog and checking any function that Travis
>>> quietly commits is no fun (see mailing list for the introduction of
>>> curve_fit or ask Stefan).
>>>
>>> I said early on that I would like to trust the results that
>>> scipy.stats produces (although I don't find the mailing list thread
>>> any more).
>>>
>>> I considered scipy to go into a stable direction like Python is,
>>> kitchen sink for scientific programming, which might be slow-moving
>>> but with high standards, and not a sandbox.
>>>
>>> Details are at
>>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>>
>>> After my initial scipy.stats.distributions cleanup, test coverage was
>>> at 91%, I have no idea where it is after this weekend.
>>>
>>> This is more about the process then the content, distributions was
>>> Travis's baby (although unfinished), and most of his changes are very
>>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>>
>>
>> Ah Josef, there are easier ways to lodge complaints than resignation ;) I
>> agree that it was rude of Travis to make those changes without running them
>> through the list, and he does tend to toss stuff in that others have to
>> clean up, the same with c-code. But maybe we can manage to get him
>> housebroken without all moving out.
>>
>
> I think a policy of mandatory review will solve these sorts of problems, and
> that is probably a good argument for moving to github where review is much
> easier. On stats, we probably need an additional policy of rigorous testing
> to make sure that things are working right, the stat tests are more
> difficult by their very nature. I think Travis is amenable to such
> processes, but we do need to start a discussion. If you do feel strongly
> about the recent changes maybe they can be reverted and added back in after
> review.
>

I am perhaps wading out of my depth here, but I agree with the
concerns and having the proposed dialogue, as I think having Josef's
input on the direction of scipy.stats is important.

This does dovetail with the move to DVCS/github and having a review
and discussion policy in place before things go into trunk.  I don't
recall there being a time frame set up for the move (?) though there
was little dissent in actually making the move.  Perhaps we could
start hashing out concrete plans for review and a renewed policy for
testing standards so that the discussions can focus more on design and
as little energy as possible is spent uncovering precision errors,
typos, and niggling bugs.  Does it make sense to do this before the
move maybe as part of the docs marathon?  Of course there were also
those in favor of shoot first, sort it out as we go along because this
is a problem that has been solved before.

Re:testing, the things that go into stats must be as test driven as
possible given that there are plenty of choices of where to turn to do
statistics work.  The econometricians that I have talked to who
develop in R tell me Python is a "dark horse" for choice of language
and having undiscovered precision errors etc., to say nothing about
actual design, does not help our case.

Skipper


From ralf.gommers at googlemail.com  Mon May 31 11:35:41 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Mon, 31 May 2010 23:35:41 +0800
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikXZskHHj-ib6Cg8kb0XD0_i5RfmQrR2gupaDwU@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
	<AANLkTik6VK1qJC9h3END9pGHHdOOQ197WHEf_GSKqn5x@mail.gmail.com>
	<AANLkTikXZskHHj-ib6Cg8kb0XD0_i5RfmQrR2gupaDwU@mail.gmail.com>
Message-ID: <AANLkTimeu3ir62bjCUJchMING8fwJxoLuhj6M3XyZ_ne@mail.gmail.com>

On Mon, May 31, 2010 at 11:14 PM, <josef.pktd at gmail.com> wrote:

>
> My approach has been to block any untested, non-trivial changes, and
> to review and test changes by others, so we don't increase the amount
> of "technological debt".
>

This is an approach I would like to see, not only for stats but for all of
numpy and scipy. And with the enthusiasm about moving to github it can be
done easily and quickly.

I hope you decide to stick around Josef.

Cheers,
Ralf


> The second part is testing and verification of existing functions
> (finish the statistical review which has been lingering for several
> years), which is slow going because I'm almost the only one doing it.
>
> The third part is develop enhancements and prepare for a consistent
> refactoring of "statistics in python" in a sandbox outside of scipy.
> (Here, I admit I have a small conflict of interest getting things
> quickly into scipy, because I'm more interested in "Statistics in
> Python" than statistics in scipy.)
>
> I have been a bit slow working on scipy trunk in the last year because
> I worked more on statsmodels, and I didn't have always the time (or
> didn't feel like) keeping up with recompiling numpy/scipy.
>
> (My alternative is to develop pythonstats completely outside of
> scipy.stats, maintaining a smaller set of verified functions and just
> ignore scipy.stats for now.)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/8a27fd2a/attachment.html>

From charlesr.harris at gmail.com  Mon May 31 11:50:47 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 09:50:47 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
Message-ID: <AANLkTilPiWfCSpCSB0T_l1a_IoKdr5bU8VhVDFK9X11x@mail.gmail.com>

On Mon, May 31, 2010 at 9:32 AM, Skipper Seabold <jsseabold at gmail.com>wrote:

> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >>
> >>
> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
> >>>
> >>> Since Travis seems to want to take back control of scipy.stats, I am
> >>> considering my role as inofficial maintainer as ended.
> >>>
> >>> I would have appreciated his help almost 3 years ago, when I started
> >>> to learn numpy, scipy, and started to submit patches for
> >>> scipy.stats.distributions.
> >>>
> >>> But by now, I have pretty strong opinions about statistics in python,
> >>> after almost  three years, I'm a bit tired of cleaning up the mess of
> >>> others (and want to clean up my own mess), and there are obviously big
> >>> philosophical differences for the development process between me and
> >>> Travis (no discussion, no review, no tests).
> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
> >>>
> >>> Watching the scipy changelog and checking any function that Travis
> >>> quietly commits is no fun (see mailing list for the introduction of
> >>> curve_fit or ask Stefan).
> >>>
> >>> I said early on that I would like to trust the results that
> >>> scipy.stats produces (although I don't find the mailing list thread
> >>> any more).
> >>>
> >>> I considered scipy to go into a stable direction like Python is,
> >>> kitchen sink for scientific programming, which might be slow-moving
> >>> but with high standards, and not a sandbox.
> >>>
> >>> Details are at
> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
> >>>
> >>> After my initial scipy.stats.distributions cleanup, test coverage was
> >>> at 91%, I have no idea where it is after this weekend.
> >>>
> >>> This is more about the process then the content, distributions was
> >>> Travis's baby (although unfinished), and most of his changes are very
> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
> >>>
> >>
> >> Ah Josef, there are easier ways to lodge complaints than resignation ;)
> I
> >> agree that it was rude of Travis to make those changes without running
> them
> >> through the list, and he does tend to toss stuff in that others have to
> >> clean up, the same with c-code. But maybe we can manage to get him
> >> housebroken without all moving out.
> >>
> >
> > I think a policy of mandatory review will solve these sorts of problems,
> and
> > that is probably a good argument for moving to github where review is
> much
> > easier. On stats, we probably need an additional policy of rigorous
> testing
> > to make sure that things are working right, the stat tests are more
> > difficult by their very nature. I think Travis is amenable to such
> > processes, but we do need to start a discussion. If you do feel strongly
> > about the recent changes maybe they can be reverted and added back in
> after
> > review.
> >
>
> I am perhaps wading out of my depth here, but I agree with the
> concerns and having the proposed dialogue, as I think having Josef's
> input on the direction of scipy.stats is important.
>
> This does dovetail with the move to DVCS/github and having a review
> and discussion policy in place before things go into trunk.  I don't
> recall there being a time frame set up for the move (?) though there
> was little dissent in actually making the move.  Perhaps we could
> start hashing out concrete plans for review and a renewed policy for
> testing standards so that the discussions can focus more on design and
> as little energy as possible is spent uncovering precision errors,
> typos, and niggling bugs.  Does it make sense to do this before the
> move maybe as part of the docs marathon?  Of course there were also
> those in favor of shoot first, sort it out as we go along because this
> is a problem that has been solved before.
>
> Re:testing, the things that go into stats must be as test driven as
> possible given that there are plenty of choices of where to turn to do
> statistics work.  The econometricians that I have talked to who
> develop in R tell me Python is a "dark horse" for choice of language
> and having undiscovered precision errors etc., to say nothing about
> actual design, does not help our case.
>
>
With this in mind, perhaps it would be best to revert the changes so that
there is a clean starting point; we can keep them somewhere else for
review.  The discussion of process can then take place without dealing with
the specifics of the recent commits.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/45618983/attachment.html>

From josef.pktd at gmail.com  Mon May 31 12:06:51 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 31 May 2010 12:06:51 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTilPiWfCSpCSB0T_l1a_IoKdr5bU8VhVDFK9X11x@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
	<AANLkTilPiWfCSpCSB0T_l1a_IoKdr5bU8VhVDFK9X11x@mail.gmail.com>
Message-ID: <AANLkTilgGw0QGOKgDENxoCfw-INUsFjrscVwCgWpbrwg@mail.gmail.com>

On Mon, May 31, 2010 at 11:50 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, May 31, 2010 at 9:32 AM, Skipper Seabold <jsseabold at gmail.com>
> wrote:
>>
>> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> >
>> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
>> > <charlesr.harris at gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>> >>>
>> >>> Since Travis seems to want to take back control of scipy.stats, I am
>> >>> considering my role as inofficial maintainer as ended.
>> >>>
>> >>> I would have appreciated his help almost 3 years ago, when I started
>> >>> to learn numpy, scipy, and started to submit patches for
>> >>> scipy.stats.distributions.
>> >>>
>> >>> But by now, I have pretty strong opinions about statistics in python,
>> >>> after almost ?three years, I'm a bit tired of cleaning up the mess of
>> >>> others (and want to clean up my own mess), and there are obviously big
>> >>> philosophical differences for the development process between me and
>> >>> Travis (no discussion, no review, no tests).
>> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>> >>>
>> >>> Watching the scipy changelog and checking any function that Travis
>> >>> quietly commits is no fun (see mailing list for the introduction of
>> >>> curve_fit or ask Stefan).
>> >>>
>> >>> I said early on that I would like to trust the results that
>> >>> scipy.stats produces (although I don't find the mailing list thread
>> >>> any more).
>> >>>
>> >>> I considered scipy to go into a stable direction like Python is,
>> >>> kitchen sink for scientific programming, which might be slow-moving
>> >>> but with high standards, and not a sandbox.
>> >>>
>> >>> Details are at
>> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>> >>>
>> >>> After my initial scipy.stats.distributions cleanup, test coverage was
>> >>> at 91%, I have no idea where it is after this weekend.
>> >>>
>> >>> This is more about the process then the content, distributions was
>> >>> Travis's baby (although unfinished), and most of his changes are very
>> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
>> >>>
>> >>
>> >> Ah Josef, there are easier ways to lodge complaints than resignation ;)
>> >> I
>> >> agree that it was rude of Travis to make those changes without running
>> >> them
>> >> through the list, and he does tend to toss stuff in that others have to
>> >> clean up, the same with c-code. But maybe we can manage to get him
>> >> housebroken without all moving out.
>> >>
>> >
>> > I think a policy of mandatory review will solve these sorts of problems,
>> > and
>> > that is probably a good argument for moving to github where review is
>> > much
>> > easier. On stats, we probably need an additional policy of rigorous
>> > testing
>> > to make sure that things are working right, the stat tests are more
>> > difficult by their very nature. I think Travis is amenable to such
>> > processes, but we do need to start a discussion. If you do feel strongly
>> > about the recent changes maybe they can be reverted and added back in
>> > after
>> > review.
>> >
>>
>> I am perhaps wading out of my depth here, but I agree with the
>> concerns and having the proposed dialogue, as I think having Josef's
>> input on the direction of scipy.stats is important.
>>
>> This does dovetail with the move to DVCS/github and having a review
>> and discussion policy in place before things go into trunk. ?I don't
>> recall there being a time frame set up for the move (?) though there
>> was little dissent in actually making the move. ?Perhaps we could
>> start hashing out concrete plans for review and a renewed policy for
>> testing standards so that the discussions can focus more on design and
>> as little energy as possible is spent uncovering precision errors,
>> typos, and niggling bugs. ?Does it make sense to do this before the
>> move maybe as part of the docs marathon? ?Of course there were also
>> those in favor of shoot first, sort it out as we go along because this
>> is a problem that has been solved before.
>>
>> Re:testing, the things that go into stats must be as test driven as
>> possible given that there are plenty of choices of where to turn to do
>> statistics work. ?The econometricians that I have talked to who
>> develop in R tell me Python is a "dark horse" for choice of language
>> and having undiscovered precision errors etc., to say nothing about
>> actual design, does not help our case.
>>
>
> With this in mind, perhaps it would be best to revert the changes so that
> there is a clean starting point; we can keep them somewhere else for
> review.? The discussion of process can then take place without dealing with
> the specifics of the recent commits.

Or someone writes the tests for them and fixes possible problems, then
I don't think it's a problem to keep them.

Josef

>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From charlesr.harris at gmail.com  Mon May 31 12:32:18 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 10:32:18 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTilgGw0QGOKgDENxoCfw-INUsFjrscVwCgWpbrwg@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
	<AANLkTilPiWfCSpCSB0T_l1a_IoKdr5bU8VhVDFK9X11x@mail.gmail.com>
	<AANLkTilgGw0QGOKgDENxoCfw-INUsFjrscVwCgWpbrwg@mail.gmail.com>
Message-ID: <AANLkTikdaOvv9QbflOIWqqTQ7NvydAHnrJy400XpgycT@mail.gmail.com>

On Mon, May 31, 2010 at 10:06 AM, <josef.pktd at gmail.com> wrote:

> On Mon, May 31, 2010 at 11:50 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Mon, May 31, 2010 at 9:32 AM, Skipper Seabold <jsseabold at gmail.com>
> > wrote:
> >>
> >> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >> >
> >> >
> >> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
> >> > <charlesr.harris at gmail.com> wrote:
> >> >>
> >> >>
> >> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
> >> >>>
> >> >>> Since Travis seems to want to take back control of scipy.stats, I am
> >> >>> considering my role as inofficial maintainer as ended.
> >> >>>
> >> >>> I would have appreciated his help almost 3 years ago, when I started
> >> >>> to learn numpy, scipy, and started to submit patches for
> >> >>> scipy.stats.distributions.
> >> >>>
> >> >>> But by now, I have pretty strong opinions about statistics in
> python,
> >> >>> after almost  three years, I'm a bit tired of cleaning up the mess
> of
> >> >>> others (and want to clean up my own mess), and there are obviously
> big
> >> >>> philosophical differences for the development process between me and
> >> >>> Travis (no discussion, no review, no tests).
> >> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
> >> >>>
> >> >>> Watching the scipy changelog and checking any function that Travis
> >> >>> quietly commits is no fun (see mailing list for the introduction of
> >> >>> curve_fit or ask Stefan).
> >> >>>
> >> >>> I said early on that I would like to trust the results that
> >> >>> scipy.stats produces (although I don't find the mailing list thread
> >> >>> any more).
> >> >>>
> >> >>> I considered scipy to go into a stable direction like Python is,
> >> >>> kitchen sink for scientific programming, which might be slow-moving
> >> >>> but with high standards, and not a sandbox.
> >> >>>
> >> >>> Details are at
> >> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
> >> >>>
> >> >>> After my initial scipy.stats.distributions cleanup, test coverage
> was
> >> >>> at 91%, I have no idea where it is after this weekend.
> >> >>>
> >> >>> This is more about the process then the content, distributions was
> >> >>> Travis's baby (although unfinished), and most of his changes are
> very
> >> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
> >> >>>
> >> >>
> >> >> Ah Josef, there are easier ways to lodge complaints than resignation
> ;)
> >> >> I
> >> >> agree that it was rude of Travis to make those changes without
> running
> >> >> them
> >> >> through the list, and he does tend to toss stuff in that others have
> to
> >> >> clean up, the same with c-code. But maybe we can manage to get him
> >> >> housebroken without all moving out.
> >> >>
> >> >
> >> > I think a policy of mandatory review will solve these sorts of
> problems,
> >> > and
> >> > that is probably a good argument for moving to github where review is
> >> > much
> >> > easier. On stats, we probably need an additional policy of rigorous
> >> > testing
> >> > to make sure that things are working right, the stat tests are more
> >> > difficult by their very nature. I think Travis is amenable to such
> >> > processes, but we do need to start a discussion. If you do feel
> strongly
> >> > about the recent changes maybe they can be reverted and added back in
> >> > after
> >> > review.
> >> >
> >>
> >> I am perhaps wading out of my depth here, but I agree with the
> >> concerns and having the proposed dialogue, as I think having Josef's
> >> input on the direction of scipy.stats is important.
> >>
> >> This does dovetail with the move to DVCS/github and having a review
> >> and discussion policy in place before things go into trunk.  I don't
> >> recall there being a time frame set up for the move (?) though there
> >> was little dissent in actually making the move.  Perhaps we could
> >> start hashing out concrete plans for review and a renewed policy for
> >> testing standards so that the discussions can focus more on design and
> >> as little energy as possible is spent uncovering precision errors,
> >> typos, and niggling bugs.  Does it make sense to do this before the
> >> move maybe as part of the docs marathon?  Of course there were also
> >> those in favor of shoot first, sort it out as we go along because this
> >> is a problem that has been solved before.
> >>
> >> Re:testing, the things that go into stats must be as test driven as
> >> possible given that there are plenty of choices of where to turn to do
> >> statistics work.  The econometricians that I have talked to who
> >> develop in R tell me Python is a "dark horse" for choice of language
> >> and having undiscovered precision errors etc., to say nothing about
> >> actual design, does not help our case.
> >>
> >
> > With this in mind, perhaps it would be best to revert the changes so that
> > there is a clean starting point; we can keep them somewhere else for
> > review.  The discussion of process can then take place without dealing
> with
> > the specifics of the recent commits.
>
> Or someone writes the tests for them and fixes possible problems, then
> I don't think it's a problem to keep them.
>
>
I think the policy has to be that additions *must* come with tests and
documentation. If the recent changes don't meet that criterion, then they
must be taken out. The policy has to be established at some point. Places
where we can afford to be less strict are simple bug fixes, or totally new
projects unrelated to current contents, where a certain period of shaking
out is to be expected, but for modifications to existing areas I believe
more care needs to be taken. Projects grow and mature, and what was
acceptable or even essential early on can become counter-productive.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/5ab3054a/attachment.html>

From warren.weckesser at enthought.com  Mon May 31 13:21:19 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 31 May 2010 12:21:19 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
Message-ID: <4C03F00F.3020806@enthought.com>

David Cournapeau wrote:
> On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
> <warren.weckesser at enthought.com> wrote:
>   
>> David Cournapeau wrote:
>>     
>>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>>> <warren.weckesser at enthought.com> wrote:
>>>
>>>
>>>
>>>       
>>>> What I would like to do is leave trunk as it is, and after 0.8 is
>>>> branched, make the appropriate changes in the branch to follow the
>>>> deprecation policy.  Is that a reasonable approach?
>>>>
>>>>         
>>> May I ask why do you want to do that way ?
>>>       
>> Because it doesn't look like I will have time to make the changes before
>> Ralf branches 0.8 tomorrow.
>>
>>     
>>>  Putting the deprecation in
>>> the release branch means people tracking trunk will never see them.
>>>
>>>       
>> Good point.    But in case I am misinterpreting what you mean by
>> "tracking trunk" and "see":  I assume this means it is important to have
>> a record of the deprecation changes in the svn logs, and not that some
>> who is *using* scipy from trunk also needs to be exposed to the
>> deprecation warning for some minimum amount of time.
>>     
>
> actually, I meant both. For example, I often use scipy from trunk, and
> rarely from releases.  I will never see the deprecation, which is not
> good.
>
> Also, I think we should generally try to never put things in release
> branches, but always backport from trunk (except for branch specific
> changes). Having the 0.8 branch created tomorrow does not mean you
> cannot put the changes into trunk, and backport them in 0.8 later -
> deprecation which were already agreed on are the kind of things which
> can happen after the branching without putting much burden on the
> release process.
>
>   
>>  If the changes are
>> made to trunk, then they will be undone immediately after 0.8 is
>> branched.
>>     
>
> deprecated features do not be to be removed just after the trunk is
> opened for the next release cycle (0.9 here).
>
>   
>> ever have a copy that includes the deprecation warnings.  In other
>> words, deprecations are linked to releases, not to "time in trunk".
>>     
>
> Indeed - but I think that we should let the deprecation be in place
> for as long as possible in the source code repository.
>
>   


OK.  It might be a couple more days before I can make the reversions and 
deprecations, but I'll get them in before the beta release on June 6.

Warren




From d.l.goldsmith at gmail.com  Mon May 31 13:25:11 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 10:25:11 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTim-z190W1CdgfVnnQ-iaqbZ1d096YgR9rMfVwEf@mail.gmail.com>
Message-ID: <AANLkTilAiI5upncIpn_musmDOBn_CIzPdxfKHoV1RNoo@mail.gmail.com>

On Mon, May 31, 2010 at 7:28 AM, <josef.pktd at gmail.com> wrote:

> On Mon, May 31, 2010 at 10:23 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> >
> > On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
> >>
> >> Since Travis seems to want to take back control of scipy.stats, I am
> >> considering my role as inofficial maintainer as ended.
> >>
> >> I would have appreciated his help almost 3 years ago, when I started
> >> to learn numpy, scipy, and started to submit patches for
> >> scipy.stats.distributions.
> >>
> >> But by now, I have pretty strong opinions about statistics in python,
> >> after almost  three years, I'm a bit tired of cleaning up the mess of
> >> others (and want to clean up my own mess), and there are obviously big
> >> philosophical differences for the development process between me and
> >> Travis (no discussion, no review, no tests).
> >> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
> >>
> >> Watching the scipy changelog and checking any function that Travis
> >> quietly commits is no fun (see mailing list for the introduction of
> >> curve_fit or ask Stefan).
> >>
> >> I said early on that I would like to trust the results that
> >> scipy.stats produces (although I don't find the mailing list thread
> >> any more).
> >>
> >> I considered scipy to go into a stable direction like Python is,
> >> kitchen sink for scientific programming, which might be slow-moving
> >> but with high standards, and not a sandbox.
> >>
> >> Details are at
> >> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
> >>
> >> After my initial scipy.stats.distributions cleanup, test coverage was
> >> at 91%, I have no idea where it is after this weekend.
> >>
> >> This is more about the process then the content, distributions was
> >> Travis's baby (although unfinished), and most of his changes are very
> >> good, but I don't want to look for the 5-10% (?) typos anymore.
> >>
> >
> > Ah Josef, there are easier ways to lodge complaints than resignation ;) I
> > agree that it was rude of Travis to make those changes without running
> them
> > through the list, and he does tend to toss stuff in that others have to
> > clean up, the same with c-code. But maybe we can manage to get him
> > housebroken without all moving out.
>
> I think the discussion with him occurred already several times on the
> lists.
>

Right.  I don't think we can house break him 'cause he feels like he owns
the house; I think he thinks of himself as our (NS)BDFL.

DG


>
> Josef
>
>
> > Chuck
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/351db808/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 31 13:27:27 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 10:27:27 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
Message-ID: <AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>

On Mon, May 31, 2010 at 7:38 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
> On Mon, May 31, 2010 at 8:23 AM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>>
>>> Since Travis seems to want to take back control of scipy.stats, I am
>>> considering my role as inofficial maintainer as ended.
>>>
>>> I would have appreciated his help almost 3 years ago, when I started
>>> to learn numpy, scipy, and started to submit patches for
>>> scipy.stats.distributions.
>>>
>>> But by now, I have pretty strong opinions about statistics in python,
>>> after almost  three years, I'm a bit tired of cleaning up the mess of
>>> others (and want to clean up my own mess), and there are obviously big
>>> philosophical differences for the development process between me and
>>> Travis (no discussion, no review, no tests).
>>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>>
>>> Watching the scipy changelog and checking any function that Travis
>>> quietly commits is no fun (see mailing list for the introduction of
>>> curve_fit or ask Stefan).
>>>
>>> I said early on that I would like to trust the results that
>>> scipy.stats produces (although I don't find the mailing list thread
>>> any more).
>>>
>>> I considered scipy to go into a stable direction like Python is,
>>> kitchen sink for scientific programming, which might be slow-moving
>>> but with high standards, and not a sandbox.
>>>
>>> Details are at
>>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>>
>>> After my initial scipy.stats.distributions cleanup, test coverage was
>>> at 91%, I have no idea where it is after this weekend.
>>>
>>> This is more about the process then the content, distributions was
>>> Travis's baby (although unfinished), and most of his changes are very
>>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>>
>>>
>> Ah Josef, there are easier ways to lodge complaints than resignation ;) I
>> agree that it was rude of Travis to make those changes without running them
>> through the list, and he does tend to toss stuff in that others have to
>> clean up, the same with c-code. But maybe we can manage to get him
>> housebroken without all moving out.
>>
>>
> I think a policy of mandatory review will solve these sorts of problems,
> and that is probably a good argument for moving to github where review is
> much easier. On stats, we probably need an additional policy of rigorous
> testing to make sure that things are working right, the stat tests are more
> difficult by their very nature. I think Travis is amenable to such
> processes,
>

I think Travis will *say* (has said) that he is so amenable, but his actions
say otherwise.

DG


> but we do need to start a discussion. If you do feel strongly about the
> recent changes maybe they can be reverted and added back in after review.
>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/258b5603/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 31 13:43:11 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 10:43:11 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
Message-ID: <AANLkTikVRLqU_lfWbZANkwMWG8y6G7319oFKJRJdJ92X@mail.gmail.com>

On Mon, May 31, 2010 at 8:32 AM, Skipper Seabold <jsseabold at gmail.com>wrote:

> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
> > <charlesr.harris at gmail.com> wrote:
> >>
> >>
> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
> >>>
> >>> Since Travis seems to want to take back control of scipy.stats, I am
> >>> considering my role as inofficial maintainer as ended.
> >>>
> >>> I would have appreciated his help almost 3 years ago, when I started
> >>> to learn numpy, scipy, and started to submit patches for
> >>> scipy.stats.distributions.
> >>>
> >>> But by now, I have pretty strong opinions about statistics in python,
> >>> after almost  three years, I'm a bit tired of cleaning up the mess of
> >>> others (and want to clean up my own mess), and there are obviously big
> >>> philosophical differences for the development process between me and
> >>> Travis (no discussion, no review, no tests).
> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
> >>>
> >>> Watching the scipy changelog and checking any function that Travis
> >>> quietly commits is no fun (see mailing list for the introduction of
> >>> curve_fit or ask Stefan).
> >>>
> >>> I said early on that I would like to trust the results that
> >>> scipy.stats produces (although I don't find the mailing list thread
> >>> any more).
> >>>
> >>> I considered scipy to go into a stable direction like Python is,
> >>> kitchen sink for scientific programming, which might be slow-moving
> >>> but with high standards, and not a sandbox.
> >>>
> >>> Details are at
> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
> >>>
> >>> After my initial scipy.stats.distributions cleanup, test coverage was
> >>> at 91%, I have no idea where it is after this weekend.
> >>>
> >>> This is more about the process then the content, distributions was
> >>> Travis's baby (although unfinished), and most of his changes are very
> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
> >>>
> >>
> >> Ah Josef, there are easier ways to lodge complaints than resignation ;)
> I
> >> agree that it was rude of Travis to make those changes without running
> them
> >> through the list, and he does tend to toss stuff in that others have to
> >> clean up, the same with c-code. But maybe we can manage to get him
> >> housebroken without all moving out.
> >>
> >
> > I think a policy of mandatory review will solve these sorts of problems,
> and
> > that is probably a good argument for moving to github where review is
> much
> > easier. On stats, we probably need an additional policy of rigorous
> testing
> > to make sure that things are working right, the stat tests are more
> > difficult by their very nature. I think Travis is amenable to such
> > processes, but we do need to start a discussion. If you do feel strongly
> > about the recent changes maybe they can be reverted and added back in
> after
> > review.
> >
>
> I am perhaps wading out of my depth here, but I agree with the
> concerns and having the proposed dialogue, as I think having Josef's
> input on the direction of scipy.stats is important.
>
> This does dovetail with the move to DVCS/github and having a review
> and discussion policy in place before things go into trunk.  I don't
> recall there being a time frame set up for the move (?) though there
> was little dissent in actually making the move.  Perhaps we could
> start hashing out concrete plans for review and a renewed policy for
> testing standards so that the discussions can focus more on design and
> as little energy as possible is spent uncovering precision errors,
> typos, and niggling bugs.  Does it make sense to do this before the
> move maybe as part of the docs marathon?  Of course there were also
> those in favor of shoot first, sort it out as we go along because this
> is a problem that has been solved before.
>
> Re:testing, the things that go into stats must be as test driven as
> possible


As in Test Driven
Development<http://en.wikipedia.org/wiki/Test_driven_development>?
Hear hear!  This would force (stats) developers to think first about
developing tests to verify the correctness of the more esoteric aspects of
the desired results of the algorithm they're working on, and would make it
much less likely that code would be submitted w/out tests (if you had to
write the tests first, why are you submitting code w/out tests?)  Obviously,
this would need to be "strongly advised," as we have no way of enforcing how
people actually write code, but we certainly could enforce that code w/out
tests (and/or without Standards compliant docstrings) won't even be
reviewed.

DG


> given that there are plenty of choices of where to turn to do
> statistics work.  The econometricians that I have talked to who
> develop in R tell me Python is a "dark horse" for choice of language
> and having undiscovered precision errors etc., to say nothing about
> actual design, does not help our case.
>
> Skipper
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>



-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/1c0f028c/attachment.html>

From d.l.goldsmith at gmail.com  Mon May 31 13:58:23 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 10:58:23 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikdaOvv9QbflOIWqqTQ7NvydAHnrJy400XpgycT@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
	<AANLkTilPiWfCSpCSB0T_l1a_IoKdr5bU8VhVDFK9X11x@mail.gmail.com>
	<AANLkTilgGw0QGOKgDENxoCfw-INUsFjrscVwCgWpbrwg@mail.gmail.com>
	<AANLkTikdaOvv9QbflOIWqqTQ7NvydAHnrJy400XpgycT@mail.gmail.com>
Message-ID: <AANLkTikrTw1raZE1JHVMqzylBr1yS4zIYXaWh-WmmsSN@mail.gmail.com>

On Mon, May 31, 2010 at 9:32 AM, Charles R Harris <charlesr.harris at gmail.com
> wrote:

>
> I think the policy has to be that additions *must* come with tests and
> documentation. If the
>

I was under the (mistaken?) impression that that *is* policy; the question
is, are there consequences (besides alienating individuals in the community)
for flaunting that policy?


> recent changes don't meet that criterion, then they must be taken out. The
> policy has to be established at some point. Places where we can afford to be
> less strict are simple bug fixes, or totally new projects unrelated to
> current contents, where a certain period of shaking out is to be expected,
>

Yes, but IMO, the tests and the doc should be part of that "shaking out,"
i.e., I strongly disagree, I feel strongly that "totally new projects"
should be subject to The Policy as well.

DG


> but for modifications to existing areas I believe more care needs to be
> taken. Projects grow and mature, and what was acceptable or even essential
> early on can become counter-productive.
>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/db65ccbb/attachment.html>

From josef.pktd at gmail.com  Mon May 31 14:03:20 2010
From: josef.pktd at gmail.com (josef.pktd at gmail.com)
Date: Mon, 31 May 2010 14:03:20 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikVRLqU_lfWbZANkwMWG8y6G7319oFKJRJdJ92X@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com>
	<AANLkTikVRLqU_lfWbZANkwMWG8y6G7319oFKJRJdJ92X@mail.gmail.com>
Message-ID: <AANLkTimqHnwLfXWfhmJqdrixULHC9dmJe1p715YzxgkC@mail.gmail.com>

On Mon, May 31, 2010 at 1:43 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Mon, May 31, 2010 at 8:32 AM, Skipper Seabold <jsseabold at gmail.com>
> wrote:
>>
>> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
>> > <charlesr.harris at gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>> >>>
>> >>> Since Travis seems to want to take back control of scipy.stats, I am
>> >>> considering my role as inofficial maintainer as ended.
>> >>>
>> >>> I would have appreciated his help almost 3 years ago, when I started
>> >>> to learn numpy, scipy, and started to submit patches for
>> >>> scipy.stats.distributions.
>> >>>
>> >>> But by now, I have pretty strong opinions about statistics in python,
>> >>> after almost ?three years, I'm a bit tired of cleaning up the mess of
>> >>> others (and want to clean up my own mess), and there are obviously big
>> >>> philosophical differences for the development process between me and
>> >>> Travis (no discussion, no review, no tests).
>> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>> >>>
>> >>> Watching the scipy changelog and checking any function that Travis
>> >>> quietly commits is no fun (see mailing list for the introduction of
>> >>> curve_fit or ask Stefan).
>> >>>
>> >>> I said early on that I would like to trust the results that
>> >>> scipy.stats produces (although I don't find the mailing list thread
>> >>> any more).
>> >>>
>> >>> I considered scipy to go into a stable direction like Python is,
>> >>> kitchen sink for scientific programming, which might be slow-moving
>> >>> but with high standards, and not a sandbox.
>> >>>
>> >>> Details are at
>> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>> >>>
>> >>> After my initial scipy.stats.distributions cleanup, test coverage was
>> >>> at 91%, I have no idea where it is after this weekend.
>> >>>
>> >>> This is more about the process then the content, distributions was
>> >>> Travis's baby (although unfinished), and most of his changes are very
>> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
>> >>>
>> >>
>> >> Ah Josef, there are easier ways to lodge complaints than resignation ;)
>> >> I
>> >> agree that it was rude of Travis to make those changes without running
>> >> them
>> >> through the list, and he does tend to toss stuff in that others have to
>> >> clean up, the same with c-code. But maybe we can manage to get him
>> >> housebroken without all moving out.
>> >>
>> >
>> > I think a policy of mandatory review will solve these sorts of problems,
>> > and
>> > that is probably a good argument for moving to github where review is
>> > much
>> > easier. On stats, we probably need an additional policy of rigorous
>> > testing
>> > to make sure that things are working right, the stat tests are more
>> > difficult by their very nature. I think Travis is amenable to such
>> > processes, but we do need to start a discussion. If you do feel strongly
>> > about the recent changes maybe they can be reverted and added back in
>> > after
>> > review.
>> >
>>
>> I am perhaps wading out of my depth here, but I agree with the
>> concerns and having the proposed dialogue, as I think having Josef's
>> input on the direction of scipy.stats is important.
>>
>> This does dovetail with the move to DVCS/github and having a review
>> and discussion policy in place before things go into trunk. ?I don't
>> recall there being a time frame set up for the move (?) though there
>> was little dissent in actually making the move. ?Perhaps we could
>> start hashing out concrete plans for review and a renewed policy for
>> testing standards so that the discussions can focus more on design and
>> as little energy as possible is spent uncovering precision errors,
>> typos, and niggling bugs. ?Does it make sense to do this before the
>> move maybe as part of the docs marathon? ?Of course there were also
>> those in favor of shoot first, sort it out as we go along because this
>> is a problem that has been solved before.
>>
>> Re:testing, the things that go into stats must be as test driven as
>> possible
>
> As in Test Driven Development?? Hear hear!? This would force (stats)
> developers to think first about developing tests to verify the correctness
> of the more esoteric aspects of the desired results of the algorithm they're
> working on, and would make it much less likely that code would be submitted
> w/out tests (if you had to write the tests first, why are you submitting
> code w/out tests?)? Obviously, this would need to be "strongly advised," as
> we have no way of enforcing how people actually write code, but we certainly
> could enforce that code w/out tests (and/or without Standards compliant
> docstrings) won't even be reviewed.

Actually, for the _logpdf, _logcdf enhancement, I had already written
the test first
http://projects.scipy.org/scipy/ticket/1184

Josef
(93% TDD)


>
> DG
>
>>
>> given that there are plenty of choices of where to turn to do
>> statistics work. ?The econometricians that I have talked to who
>> develop in R tell me Python is a "dark horse" for choice of language
>> and having undiscovered precision errors etc., to say nothing about
>> actual design, does not help our case.
>>
>> Skipper
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>
>
> --
> Mathematician: noun, someone who disavows certainty when their uncertainty
> set is non-empty, even if that set has measure zero.
>
> Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
> lies, prevents mankind from committing a general suicide. ?(As interpreted
> by Robert Graves)
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


From charlesr.harris at gmail.com  Mon May 31 14:04:12 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 12:04:12 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>
Message-ID: <AANLkTilFoniQgnI8bINZe5OtDD8PuiRthM0FIplWiK0X@mail.gmail.com>

On Mon, May 31, 2010 at 11:27 AM, David Goldsmith
<d.l.goldsmith at gmail.com>wrote:

> On Mon, May 31, 2010 at 7:38 AM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>> On Mon, May 31, 2010 at 8:23 AM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>>>
>>>> Since Travis seems to want to take back control of scipy.stats, I am
>>>> considering my role as inofficial maintainer as ended.
>>>>
>>>> I would have appreciated his help almost 3 years ago, when I started
>>>> to learn numpy, scipy, and started to submit patches for
>>>> scipy.stats.distributions.
>>>>
>>>> But by now, I have pretty strong opinions about statistics in python,
>>>> after almost  three years, I'm a bit tired of cleaning up the mess of
>>>> others (and want to clean up my own mess), and there are obviously big
>>>> philosophical differences for the development process between me and
>>>> Travis (no discussion, no review, no tests).
>>>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>>>
>>>> Watching the scipy changelog and checking any function that Travis
>>>> quietly commits is no fun (see mailing list for the introduction of
>>>> curve_fit or ask Stefan).
>>>>
>>>> I said early on that I would like to trust the results that
>>>> scipy.stats produces (although I don't find the mailing list thread
>>>> any more).
>>>>
>>>> I considered scipy to go into a stable direction like Python is,
>>>> kitchen sink for scientific programming, which might be slow-moving
>>>> but with high standards, and not a sandbox.
>>>>
>>>> Details are at
>>>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>>>
>>>> After my initial scipy.stats.distributions cleanup, test coverage was
>>>> at 91%, I have no idea where it is after this weekend.
>>>>
>>>> This is more about the process then the content, distributions was
>>>> Travis's baby (although unfinished), and most of his changes are very
>>>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>>>
>>>>
>>> Ah Josef, there are easier ways to lodge complaints than resignation ;) I
>>> agree that it was rude of Travis to make those changes without running them
>>> through the list, and he does tend to toss stuff in that others have to
>>> clean up, the same with c-code. But maybe we can manage to get him
>>> housebroken without all moving out.
>>>
>>>
>> I think a policy of mandatory review will solve these sorts of problems,
>> and that is probably a good argument for moving to github where review is
>> much easier. On stats, we probably need an additional policy of rigorous
>> testing to make sure that things are working right, the stat tests are more
>> difficult by their very nature. I think Travis is amenable to such
>> processes,
>>
>
> I think Travis will *say* (has said) that he is so amenable, but his
> actions say otherwise.
>
>
Let's keep the personal out of this and confine it to procedure, current and
prospective.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/ff376493/attachment.html>

From jsseabold at gmail.com  Mon May 31 14:22:47 2010
From: jsseabold at gmail.com (Skipper Seabold)
Date: Mon, 31 May 2010 14:22:47 -0400
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikVRLqU_lfWbZANkwMWG8y6G7319oFKJRJdJ92X@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com> 
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com> 
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com> 
	<AANLkTimYZAEptH5rrQebhNiuPJqmzT8k2DgED8uQBcVf@mail.gmail.com> 
	<AANLkTikVRLqU_lfWbZANkwMWG8y6G7319oFKJRJdJ92X@mail.gmail.com>
Message-ID: <AANLkTinvm3z2Qov510kmbw5Y0NxwUUKOgTNig8LPbxY-@mail.gmail.com>

On Mon, May 31, 2010 at 1:43 PM, David Goldsmith
<d.l.goldsmith at gmail.com> wrote:
> On Mon, May 31, 2010 at 8:32 AM, Skipper Seabold <jsseabold at gmail.com>
> wrote:
>>
>> On Mon, May 31, 2010 at 10:38 AM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>> >
>> > On Mon, May 31, 2010 at 8:23 AM, Charles R Harris
>> > <charlesr.harris at gmail.com> wrote:
>> >>
>> >>
>> >> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>> >>>
>> >>> Since Travis seems to want to take back control of scipy.stats, I am
>> >>> considering my role as inofficial maintainer as ended.
>> >>>
>> >>> I would have appreciated his help almost 3 years ago, when I started
>> >>> to learn numpy, scipy, and started to submit patches for
>> >>> scipy.stats.distributions.
>> >>>
>> >>> But by now, I have pretty strong opinions about statistics in python,
>> >>> after almost ?three years, I'm a bit tired of cleaning up the mess of
>> >>> others (and want to clean up my own mess), and there are obviously big
>> >>> philosophical differences for the development process between me and
>> >>> Travis (no discussion, no review, no tests).
>> >>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>> >>>
>> >>> Watching the scipy changelog and checking any function that Travis
>> >>> quietly commits is no fun (see mailing list for the introduction of
>> >>> curve_fit or ask Stefan).
>> >>>
>> >>> I said early on that I would like to trust the results that
>> >>> scipy.stats produces (although I don't find the mailing list thread
>> >>> any more).
>> >>>
>> >>> I considered scipy to go into a stable direction like Python is,
>> >>> kitchen sink for scientific programming, which might be slow-moving
>> >>> but with high standards, and not a sandbox.
>> >>>
>> >>> Details are at
>> >>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>> >>>
>> >>> After my initial scipy.stats.distributions cleanup, test coverage was
>> >>> at 91%, I have no idea where it is after this weekend.
>> >>>
>> >>> This is more about the process then the content, distributions was
>> >>> Travis's baby (although unfinished), and most of his changes are very
>> >>> good, but I don't want to look for the 5-10% (?) typos anymore.
>> >>>
>> >>
>> >> Ah Josef, there are easier ways to lodge complaints than resignation ;)
>> >> I
>> >> agree that it was rude of Travis to make those changes without running
>> >> them
>> >> through the list, and he does tend to toss stuff in that others have to
>> >> clean up, the same with c-code. But maybe we can manage to get him
>> >> housebroken without all moving out.
>> >>
>> >
>> > I think a policy of mandatory review will solve these sorts of problems,
>> > and
>> > that is probably a good argument for moving to github where review is
>> > much
>> > easier. On stats, we probably need an additional policy of rigorous
>> > testing
>> > to make sure that things are working right, the stat tests are more
>> > difficult by their very nature. I think Travis is amenable to such
>> > processes, but we do need to start a discussion. If you do feel strongly
>> > about the recent changes maybe they can be reverted and added back in
>> > after
>> > review.
>> >
>>
>> I am perhaps wading out of my depth here, but I agree with the
>> concerns and having the proposed dialogue, as I think having Josef's
>> input on the direction of scipy.stats is important.
>>
>> This does dovetail with the move to DVCS/github and having a review
>> and discussion policy in place before things go into trunk. ?I don't
>> recall there being a time frame set up for the move (?) though there
>> was little dissent in actually making the move. ?Perhaps we could
>> start hashing out concrete plans for review and a renewed policy for
>> testing standards so that the discussions can focus more on design and
>> as little energy as possible is spent uncovering precision errors,
>> typos, and niggling bugs. ?Does it make sense to do this before the
>> move maybe as part of the docs marathon? ?Of course there were also
>> those in favor of shoot first, sort it out as we go along because this
>> is a problem that has been solved before.
>>
>> Re:testing, the things that go into stats must be as test driven as
>> possible
>
> As in Test Driven Development?? Hear hear!? This would force (stats)
> developers to think first about developing tests to verify the correctness
> of the more esoteric aspects of the desired results of the algorithm they're
> working on, and would make it much less likely that code would be submitted
> w/out tests (if you had to write the tests first, why are you submitting
> code w/out tests?)? Obviously, this would need to be "strongly advised," as
> we have no way of enforcing how people actually write code, but we certainly
> could enforce that code w/out tests (and/or without Standards compliant
> docstrings) won't even be reviewed.
>

TDD is one of the habits that I try to follow working on statsmodels,
and I thought it was numpy/scipy policy.  The bottom line is that
writing tests is not very much fun and it's time consuming
(*especially* when you didn't write the code in the first place), but
the heavily outweighing benefits are that it helps with code reviews
for new code and makes for a more mature and stable project in the
long run.

The way that I try to work on statsmodels forces me to write
docstrings with examples and tests and I think it helps in eliciting
code reviews.

It is not strict TDD, but I make changes first in a branch, document,
and write some examples with my output versus expected results from a
statistical package (R, SAS, Stata, etc.).  I view these as pseudo
tests that become docstring examples, tutorials, and tests.  This
helps in eliciting a code review because you don't need all the
details before running the code.  You can work backwards from
input/results and then get into implementation details and discuss API
design if necessary.  The merge to trunk doesn't happen until tests
are written.  In this way it becomes "official" and is ensured to stay
correct as optimizations are made later.

This is probably far from best practice (strict TDD should probably
continue to be policy for numpy/scipy, especially incremental
improvements) and may be more idiosyncratic than anything, but I find
this to work for me.

Skipper


From d.l.goldsmith at gmail.com  Mon May 31 16:59:24 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 13:59:24 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTilFoniQgnI8bINZe5OtDD8PuiRthM0FIplWiK0X@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>
	<AANLkTilFoniQgnI8bINZe5OtDD8PuiRthM0FIplWiK0X@mail.gmail.com>
Message-ID: <AANLkTikyC4veaKZJas1K83hMbTUvmXM2XixMbiEANnCc@mail.gmail.com>

I don't think I'm being unjustly personal: I think if certain parties (is
that unpersonal enough?) flaunt community standards of practice, then they
should be called out on it - what other teeth does a policy in this sort of
community have?  But if I'm mistaken about this Policy not yet having been
promulgated/accepted, i.e., if there is no infraction on account of a
technicality, then please, say so: I'll happily retract my accusation and
apologize.

DG

On Mon, May 31, 2010 at 11:04 AM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Mon, May 31, 2010 at 11:27 AM, David Goldsmith <d.l.goldsmith at gmail.com
> > wrote:
>
>> On Mon, May 31, 2010 at 7:38 AM, Charles R Harris <
>> charlesr.harris at gmail.com> wrote:
>>
>>>
>>> On Mon, May 31, 2010 at 8:23 AM, Charles R Harris <
>>> charlesr.harris at gmail.com> wrote:
>>>
>>>>
>>>> On Mon, May 31, 2010 at 8:16 AM, <josef.pktd at gmail.com> wrote:
>>>>
>>>>> Since Travis seems to want to take back control of scipy.stats, I am
>>>>> considering my role as inofficial maintainer as ended.
>>>>>
>>>>> I would have appreciated his help almost 3 years ago, when I started
>>>>> to learn numpy, scipy, and started to submit patches for
>>>>> scipy.stats.distributions.
>>>>>
>>>>> But by now, I have pretty strong opinions about statistics in python,
>>>>> after almost  three years, I'm a bit tired of cleaning up the mess of
>>>>> others (and want to clean up my own mess), and there are obviously big
>>>>> philosophical differences for the development process between me and
>>>>> Travis (no discussion, no review, no tests).
>>>>> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>>>>>
>>>>> Watching the scipy changelog and checking any function that Travis
>>>>> quietly commits is no fun (see mailing list for the introduction of
>>>>> curve_fit or ask Stefan).
>>>>>
>>>>> I said early on that I would like to trust the results that
>>>>> scipy.stats produces (although I don't find the mailing list thread
>>>>> any more).
>>>>>
>>>>> I considered scipy to go into a stable direction like Python is,
>>>>> kitchen sink for scientific programming, which might be slow-moving
>>>>> but with high standards, and not a sandbox.
>>>>>
>>>>> Details are at
>>>>> http://mail.scipy.org/pipermail/scipy-dev/2010-April/014058.html
>>>>>
>>>>> After my initial scipy.stats.distributions cleanup, test coverage was
>>>>> at 91%, I have no idea where it is after this weekend.
>>>>>
>>>>> This is more about the process then the content, distributions was
>>>>> Travis's baby (although unfinished), and most of his changes are very
>>>>> good, but I don't want to look for the 5-10% (?) typos anymore.
>>>>>
>>>>>
>>>> Ah Josef, there are easier ways to lodge complaints than resignation ;)
>>>> I agree that it was rude of Travis to make those changes without running
>>>> them through the list, and he does tend to toss stuff in that others have to
>>>> clean up, the same with c-code. But maybe we can manage to get him
>>>> housebroken without all moving out.
>>>>
>>>>
>>> I think a policy of mandatory review will solve these sorts of problems,
>>> and that is probably a good argument for moving to github where review is
>>> much easier. On stats, we probably need an additional policy of rigorous
>>> testing to make sure that things are working right, the stat tests are more
>>> difficult by their very nature. I think Travis is amenable to such
>>> processes,
>>>
>>
>> I think Travis will *say* (has said) that he is so amenable, but his
>> actions say otherwise.
>>
>>
> Let's keep the personal out of this and confine it to procedure, current
> and prospective.
>
> Chuck
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>


-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/b1b5215f/attachment.html>

From matthew.brett at gmail.com  Mon May 31 17:15:54 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 31 May 2010 14:15:54 -0700
Subject: [SciPy-Dev] Development process (was:  scipy.stats)
Message-ID: <AANLkTin58vCwfm71xW3Mi319zq4cAPw5o6xzAPBgFDsX@mail.gmail.com>

Hi,

Sorry - I moved this thread over because it seemed to be of general
importance - both for scipy.stats but also for our working process.
I really think it's a discussion we need to have in public - either
here on the list - or in a public meeting in scipy.

On Mon, May 31, 2010 at 7:16 AM,  <josef.pktd at gmail.com> wrote:
> Since Travis seems to want to take back control of scipy.stats, I am
> considering my role as inofficial maintainer as ended.
>
> I would have appreciated his help almost 3 years ago, when I started
> to learn numpy, scipy, and started to submit patches for
> scipy.stats.distributions.
>
> But by now, I have pretty strong opinions about statistics in python,
> after almost ?three years, I'm a bit tired of cleaning up the mess of
> others (and want to clean up my own mess), and there are obviously big
> philosophical differences for the development process between me and
> Travis (no discussion, no review, no tests).
> http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests

Returning to Josef's frustration.    It seems to me there is a general
thirst for a more formal understanding of code ownership, and the
process for discussion and review of changes.

I think Josef's frustration is very important; my impression is that
Josef's work on scipy.stats has been a very large step forward for a
module that previously was seriously broken and not properly tested.

It's obvious I think that Josef is the de-facto maintainer of
scipy.stats, and it's obvious that, as maintainer, he should first -
be asked about changes, and second - should have the right of review
before acceptance.

Any maintainer would expect this, and any maintainer is going to get
annoyed if those accepted rules of behavior are not observed.

Travis - hoping you are reading this thread - does that also seem
reasonable to you?  What do you think would be the best way of
proceeding?

Best,

Matthew


From charlesr.harris at gmail.com  Mon May 31 17:16:42 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 15:16:42 -0600
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTikyC4veaKZJas1K83hMbTUvmXM2XixMbiEANnCc@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>
	<AANLkTilFoniQgnI8bINZe5OtDD8PuiRthM0FIplWiK0X@mail.gmail.com>
	<AANLkTikyC4veaKZJas1K83hMbTUvmXM2XixMbiEANnCc@mail.gmail.com>
Message-ID: <AANLkTimj9uQoDd0V9U_QDp_dsc_3KpQwTCERSUYICkOJ@mail.gmail.com>

On Mon, May 31, 2010 at 2:59 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> I don't think I'm being unjustly personal: I think if certain parties (is
> that unpersonal enough?) flaunt community standards of practice, then they
> should be called out on it - what other teeth does a policy in this sort of
> community have?  But if I'm mistaken about this Policy not yet having been
> promulgated/accepted, i.e., if there is no infraction on account of a
> technicality, then please, say so: I'll happily retract my accusation and
> apologize.
>
>
But that doesn't give you free rein to indulge in psychoanalysis as to
motives and such. What we have here is a set of insufficiently discussed and
documented last minute commits to deal with. I can sympathize with Josef
because stats has been his baby and these commits have bypassed his quality
control and made work for him. I got a similar complaint from Pierre when I
went a bit too far in touching masked arrays. We are a rather loose
community without much in the way of rules or means to enforce them, so we
have to work things out as we go. To that end it helps if the rhetoric stays
on the cool side.

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/dd77ac66/attachment.html>

From matthew.brett at gmail.com  Mon May 31 18:34:52 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 31 May 2010 15:34:52 -0700
Subject: [SciPy-Dev] scipy.stats
In-Reply-To: <AANLkTimj9uQoDd0V9U_QDp_dsc_3KpQwTCERSUYICkOJ@mail.gmail.com>
References: <AANLkTikKQK_5yyqL5BhqGPvdF9s8inag62_Z_i5gnOmz@mail.gmail.com>
	<AANLkTiksJ9LfMD8lqWj83ntHv9RXgjUzWg8zGQ1O28Yw@mail.gmail.com>
	<AANLkTilSn3AzzZaN6lr3bR-0SsrBsj2sAKXU955OGk4M@mail.gmail.com>
	<AANLkTikMyMVsX6zqPGz3PfaVRw6Y_bZ5U5xdok4I0Yde@mail.gmail.com>
	<AANLkTilFoniQgnI8bINZe5OtDD8PuiRthM0FIplWiK0X@mail.gmail.com>
	<AANLkTikyC4veaKZJas1K83hMbTUvmXM2XixMbiEANnCc@mail.gmail.com>
	<AANLkTimj9uQoDd0V9U_QDp_dsc_3KpQwTCERSUYICkOJ@mail.gmail.com>
Message-ID: <AANLkTilWIdEx-Yy-OIlxmkISGd_gEr1qGemI1mnZqpiJ@mail.gmail.com>

Hi,

> But that doesn't give you free rein to indulge in psychoanalysis as to
> motives and such. What we have here is a set of insufficiently discussed and
> documented last minute commits to deal with. I can sympathize with Josef
> because stats has been his baby and these commits have bypassed his quality
> control and made work for him. I got a similar complaint from Pierre when I
> went a bit too far in touching masked arrays. We are a rather loose
> community without much in the way of rules or means to enforce them, so we
> have to work things out as we go. To that end it helps if the rhetoric stays
> on the cool side.

Y'all probably saw I moved this over and started another thread, I
hope you don't mind.

That's absolutely right - it's good to be cool - but it's also true
that, because we have no rules, this kind of mess and bad feeling is
bound to arise.  I think honestly that unless we do find some clarity
to the (sorry) politics of the current situation, we're going to keep
losing people that we really need - like Josef - because they don't
trust our discipline to maintain the code.

See you,

Matthew


From d.l.goldsmith at gmail.com  Mon May 31 19:32:54 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 16:32:54 -0700
Subject: [SciPy-Dev] Development process (was: scipy.stats)
In-Reply-To: <AANLkTin58vCwfm71xW3Mi319zq4cAPw5o6xzAPBgFDsX@mail.gmail.com>
References: <AANLkTin58vCwfm71xW3Mi319zq4cAPw5o6xzAPBgFDsX@mail.gmail.com>
Message-ID: <AANLkTimLpSyE7np5BqSKQSmvdBQzimSkCXxg_5ZkHKbS@mail.gmail.com>

On Mon, May 31, 2010 at 2:15 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> Sorry - I moved this thread over because it seemed to be of general
> importance - both for scipy.stats but also for our working process.
> I really think it's a discussion we need to have in public - either
> here on the list - or in a public meeting in scipy.
>
> On Mon, May 31, 2010 at 7:16 AM,  <josef.pktd at gmail.com> wrote:
> > Since Travis seems to want to take back control of scipy.stats, I am
> > considering my role as inofficial maintainer as ended.
> >
> > I would have appreciated his help almost 3 years ago, when I started
> > to learn numpy, scipy, and started to submit patches for
> > scipy.stats.distributions.
> >
> > But by now, I have pretty strong opinions about statistics in python,
> > after almost  three years, I'm a bit tired of cleaning up the mess of
> > others (and want to clean up my own mess), and there are obviously big
> > philosophical differences for the development process between me and
> > Travis (no discussion, no review, no tests).
> > http://projects.scipy.org/scipy/log/trunk/scipy/stats/tests
>
> Returning to Josef's frustration.    It seems to me there is a general
> thirst for a more formal understanding of code ownership, and the
> process for discussion and review of changes.
>
> I think Josef's frustration is very important; my impression is that
> Josef's work on scipy.stats has been a very large step forward for a
> module that previously was seriously broken and not properly tested.
>
> It's obvious I think that Josef is the de-facto maintainer of
> scipy.stats, and it's obvious that, as maintainer, he should first -
> be asked about changes, and second - should have the right of review
> before acceptance.
>
> Any maintainer would expect this, and any maintainer is going to get
> annoyed if those accepted rules of behavior are not observed.
>
> Travis - hoping you are reading this thread - does that also seem
> reasonable to you?  What do you think would be the best way of
> proceeding?
>
> Best,
>
> Matthew
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>

[Quoted from the original thread]

On Mon, May 31, 2010 at 2:59 PM, David Goldsmith <d.l.goldsmith at gmail.com>wrote:

> I don't think I'm being unjustly personal: I think if certain parties (is
> that unpersonal enough?) flaunt community standards of practice, then they
> should be called out on it - what other teeth does a policy in this sort of
> community have?  But if I'm mistaken about this Policy not yet having been
> promulgated/accepted, i.e., if there is no infraction on account of a
> technicality, then please, say so: I'll happily retract my accusation and
> apologize.
>
>
> But that doesn't give you free rein to indulge in psychoanalysis as to
motives and such.

I'm sure you mean (for it's the nature of this list, is it not, that we all
have free rein to be as diplomatic, or not, as we wish) something along the
lines of: if you tone it down a bit and make it less personal, i.e., be a
bit more 'diplomatic,' then people are more likely to take you seriously.
In fact, I feel I am being diplomatic by refraining from stating what I
think should really be done; you yourself in your first reply to the
original post intimated that person(s) who shall (now) remain nameless (but
whom it was fine for you to name when the thread began) have *repeatedly*
flaunted the standards in this manner, and yet we're asked to remain patient
and continue to try to "housebreak" these infractor(s) (your metaphor -
who's being disrespectful there, comparing the infractor(s) to puppies).

I've said my piece, I'll shut up now.

DG
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/cdef517e/attachment.html>

From warren.weckesser at enthought.com  Mon May 31 19:49:35 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 31 May 2010 18:49:35 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C03F00F.3020806@enthought.com>
References: <4C012BFE.4090103@enthought.com>	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>	<4C0149EB.8030608@enthought.com>	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com>
Message-ID: <4C044B0F.4000103@enthought.com>

Opinion wanted:  codata.find(sub) used to print a list of strings.  A 
while ago, in response to http://projects.scipy.org/scipy/ticket/996,  I 
changed it to return the list of strings.  But this is an API change, 
and should follow the deprecation policy.  One way to do this is to 
restore find() to its previous behavior, and deprecate the function.  At 
the same time, add a new function, find_string(sub), which returns the 
list of strings.  What do you think?

Warren


Warren Weckesser wrote:
> David Cournapeau wrote:
>   
>> On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
>> <warren.weckesser at enthought.com> wrote:
>>   
>>     
>>> David Cournapeau wrote:
>>>     
>>>       
>>>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>>>> <warren.weckesser at enthought.com> wrote:
>>>>
>>>>
>>>>
>>>>       
>>>>         
>>>>> What I would like to do is leave trunk as it is, and after 0.8 is
>>>>> branched, make the appropriate changes in the branch to follow the
>>>>> deprecation policy.  Is that a reasonable approach?
>>>>>
>>>>>         
>>>>>           
>>>> May I ask why do you want to do that way ?
>>>>       
>>>>         
>>> Because it doesn't look like I will have time to make the changes before
>>> Ralf branches 0.8 tomorrow.
>>>
>>>     
>>>       
>>>>  Putting the deprecation in
>>>> the release branch means people tracking trunk will never see them.
>>>>
>>>>       
>>>>         
>>> Good point.    But in case I am misinterpreting what you mean by
>>> "tracking trunk" and "see":  I assume this means it is important to have
>>> a record of the deprecation changes in the svn logs, and not that some
>>> who is *using* scipy from trunk also needs to be exposed to the
>>> deprecation warning for some minimum amount of time.
>>>     
>>>       
>> actually, I meant both. For example, I often use scipy from trunk, and
>> rarely from releases.  I will never see the deprecation, which is not
>> good.
>>
>> Also, I think we should generally try to never put things in release
>> branches, but always backport from trunk (except for branch specific
>> changes). Having the 0.8 branch created tomorrow does not mean you
>> cannot put the changes into trunk, and backport them in 0.8 later -
>> deprecation which were already agreed on are the kind of things which
>> can happen after the branching without putting much burden on the
>> release process.
>>
>>   
>>     
>>>  If the changes are
>>> made to trunk, then they will be undone immediately after 0.8 is
>>> branched.
>>>     
>>>       
>> deprecated features do not be to be removed just after the trunk is
>> opened for the next release cycle (0.9 here).
>>
>>   
>>     
>>> ever have a copy that includes the deprecation warnings.  In other
>>> words, deprecations are linked to releases, not to "time in trunk".
>>>     
>>>       
>> Indeed - but I think that we should let the deprecation be in place
>> for as long as possible in the source code repository.
>>
>>   
>>     
>
>
> OK.  It might be a couple more days before I can make the reversions and 
> deprecations, but I'll get them in before the beta release on June 6.
>
> Warren
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From charlesr.harris at gmail.com  Mon May 31 20:04:25 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 18:04:25 -0600
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C044B0F.4000103@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com> <4C044B0F.4000103@enthought.com>
Message-ID: <AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>

On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Opinion wanted:  codata.find(sub) used to print a list of strings.  A
> while ago, in response to http://projects.scipy.org/scipy/ticket/996,  I
> changed it to return the list of strings.  But this is an API change,
> and should follow the deprecation policy.  One way to do this is to
> restore find() to its previous behavior, and deprecate the function.  At
> the same time, add a new function, find_string(sub), which returns the
> list of strings.  What do you think?
>
>
I wouldn't worry about this one, both have the effect of printing out on the
screen. Where is the absolute error though?

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/9df518d8/attachment.html>

From ralf.gommers at googlemail.com  Mon May 31 20:05:33 2010
From: ralf.gommers at googlemail.com (Ralf Gommers)
Date: Tue, 1 Jun 2010 08:05:33 +0800
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C03F00F.3020806@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com>
Message-ID: <AANLkTikrBpYabstlTRv_GLc7wsTUNxU2nv1F6z0A6ofG@mail.gmail.com>

On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> David Cournapeau wrote:
> > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
> > <warren.weckesser at enthought.com> wrote:
> >
> >> David Cournapeau wrote:
> >>
> >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
> >>> <warren.weckesser at enthought.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>> What I would like to do is leave trunk as it is, and after 0.8 is
> >>>> branched, make the appropriate changes in the branch to follow the
> >>>> deprecation policy.  Is that a reasonable approach?
> >>>>
> >>>>
> >>> May I ask why do you want to do that way ?
> >>>
> >> Because it doesn't look like I will have time to make the changes before
> >> Ralf branches 0.8 tomorrow.
> >>
> >>
> >>>  Putting the deprecation in
> >>> the release branch means people tracking trunk will never see them.
> >>>
> >>>
> >> Good point.    But in case I am misinterpreting what you mean by
> >> "tracking trunk" and "see":  I assume this means it is important to have
> >> a record of the deprecation changes in the svn logs, and not that some
> >> who is *using* scipy from trunk also needs to be exposed to the
> >> deprecation warning for some minimum amount of time.
> >>
> >
> > actually, I meant both. For example, I often use scipy from trunk, and
> > rarely from releases.  I will never see the deprecation, which is not
> > good.
> >
> > Also, I think we should generally try to never put things in release
> > branches, but always backport from trunk (except for branch specific
> > changes). Having the 0.8 branch created tomorrow does not mean you
> > cannot put the changes into trunk, and backport them in 0.8 later -
> > deprecation which were already agreed on are the kind of things which
> > can happen after the branching without putting much burden on the
> > release process.
> >
> >
> >>  If the changes are
> >> made to trunk, then they will be undone immediately after 0.8 is
> >> branched.
> >>
> >
> > deprecated features do not be to be removed just after the trunk is
> > opened for the next release cycle (0.9 here).
> >
> >
> >> ever have a copy that includes the deprecation warnings.  In other
> >> words, deprecations are linked to releases, not to "time in trunk".
> >>
> >
> > Indeed - but I think that we should let the deprecation be in place
> > for as long as possible in the source code repository.
> >
> >
>
>
> OK.  It might be a couple more days before I can make the reversions and
> deprecations, but I'll get them in before the beta release on June 6.
>
> The revised schedule said June 3. Next time I'll write out the months,
dd/mm vs mm/dd is obviously not so clear.

If you are still in a cleaning mood, in io there is a lot of stuff you are
allowed to remove. The 0.7.0 release notes say:

Several functions in ``scipy.io`` have been deprecated and will be
removed in the 0.8.0 release including ``npfile``, ``save``, ``load``,
``create_module``, ``create_shelf``, ``objload``, ``objsave``,
``fopen``, ``read_array``, ``write_array``, ``fread``, ``fwrite``,
``bswap``, ``packbits``, ``unpackbits``, and ``convert_objectarray``.
Some of these functions have been replaced by NumPy's raw reading and
writing capabilities, memory-mapping capabilities, or array methods.
Others have been moved from SciPy to NumPy, since basic array reading
and writing capability is now handled by NumPy.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100601/115d0e90/attachment.html>

From warren.weckesser at enthought.com  Mon May 31 20:11:32 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 31 May 2010 19:11:32 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>	<4C0149EB.8030608@enthought.com>	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>	<4C03F00F.3020806@enthought.com>
	<4C044B0F.4000103@enthought.com>
	<AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>
Message-ID: <4C045034.2000205@enthought.com>

Charles R Harris wrote:
>
>
> On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser 
> <warren.weckesser at enthought.com 
> <mailto:warren.weckesser at enthought.com>> wrote:
>
>     Opinion wanted:  codata.find(sub) used to print a list of strings.  A
>     while ago, in response to
>     http://projects.scipy.org/scipy/ticket/996,  I
>     changed it to return the list of strings.  But this is an API change,
>     and should follow the deprecation policy.  One way to do this is to
>     restore find() to its previous behavior, and deprecate the
>     function.  At
>     the same time, add a new function, find_string(sub), which returns the
>     list of strings.  What do you think?
>
>
> I wouldn't worry about this one, both have the effect of printing out 
> on the screen. Where is the absolute error though?
>

Well, I will worry about it, just not very much.  Think of it as an 
exercise in the proper implementation of the deprecation policy--a tiny 
case study.  Trivial, but with educational value. :)

What do you mean by "the absolute error"?


Warren

> Chuck
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From charlesr.harris at gmail.com  Mon May 31 20:25:26 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 18:25:26 -0600
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C045034.2000205@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com> <4C044B0F.4000103@enthought.com>
	<AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>
	<4C045034.2000205@enthought.com>
Message-ID: <AANLkTin4EwI3ddqExrDhYywT4UOlzab5VPOB2q6NwTHv@mail.gmail.com>

On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Charles R Harris wrote:
> >
> >
> > On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser
> > <warren.weckesser at enthought.com
> > <mailto:warren.weckesser at enthought.com>> wrote:
> >
> >     Opinion wanted:  codata.find(sub) used to print a list of strings.  A
> >     while ago, in response to
> >     http://projects.scipy.org/scipy/ticket/996,  I
> >     changed it to return the list of strings.  But this is an API change,
> >     and should follow the deprecation policy.  One way to do this is to
> >     restore find() to its previous behavior, and deprecate the
> >     function.  At
> >     the same time, add a new function, find_string(sub), which returns
> the
> >     list of strings.  What do you think?
> >
> >
> > I wouldn't worry about this one, both have the effect of printing out
> > on the screen. Where is the absolute error though?
> >
>
> Well, I will worry about it, just not very much.  Think of it as an
> exercise in the proper implementation of the deprecation policy--a tiny
> case study.  Trivial, but with educational value. :)
>
> What do you mean by "the absolute error"?
>

codata.precision returns the relative error. Perhaps I am mistaken, but I
thought the data was published with the absolute error. Both are useful, of
course.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/6c1f6584/attachment.html>

From warren.weckesser at enthought.com  Mon May 31 20:26:08 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 31 May 2010 19:26:08 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTikrBpYabstlTRv_GLc7wsTUNxU2nv1F6z0A6ofG@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>	<4C0149EB.8030608@enthought.com>	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>	<4C03F00F.3020806@enthought.com>
	<AANLkTikrBpYabstlTRv_GLc7wsTUNxU2nv1F6z0A6ofG@mail.gmail.com>
Message-ID: <4C0453A0.4020105@enthought.com>

Ralf Gommers wrote:
>
>
> On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser 
> <warren.weckesser at enthought.com 
> <mailto:warren.weckesser at enthought.com>> wrote:
>
>     David Cournapeau wrote:
>     > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
>     > <warren.weckesser at enthought.com
>     <mailto:warren.weckesser at enthought.com>> wrote:
>     >
>     >> David Cournapeau wrote:
>     >>
>     >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>     >>> <warren.weckesser at enthought.com
>     <mailto:warren.weckesser at enthought.com>> wrote:
>     >>>
>     >>>
>     >>>
>     >>>
>     >>>> What I would like to do is leave trunk as it is, and after 0.8 is
>     >>>> branched, make the appropriate changes in the branch to
>     follow the
>     >>>> deprecation policy.  Is that a reasonable approach?
>     >>>>
>     >>>>
>     >>> May I ask why do you want to do that way ?
>     >>>
>     >> Because it doesn't look like I will have time to make the
>     changes before
>     >> Ralf branches 0.8 tomorrow.
>     >>
>     >>
>     >>>  Putting the deprecation in
>     >>> the release branch means people tracking trunk will never see
>     them.
>     >>>
>     >>>
>     >> Good point.    But in case I am misinterpreting what you mean by
>     >> "tracking trunk" and "see":  I assume this means it is
>     important to have
>     >> a record of the deprecation changes in the svn logs, and not
>     that some
>     >> who is *using* scipy from trunk also needs to be exposed to the
>     >> deprecation warning for some minimum amount of time.
>     >>
>     >
>     > actually, I meant both. For example, I often use scipy from
>     trunk, and
>     > rarely from releases.  I will never see the deprecation, which
>     is not
>     > good.
>     >
>     > Also, I think we should generally try to never put things in release
>     > branches, but always backport from trunk (except for branch specific
>     > changes). Having the 0.8 branch created tomorrow does not mean you
>     > cannot put the changes into trunk, and backport them in 0.8 later -
>     > deprecation which were already agreed on are the kind of things
>     which
>     > can happen after the branching without putting much burden on the
>     > release process.
>     >
>     >
>     >>  If the changes are
>     >> made to trunk, then they will be undone immediately after 0.8 is
>     >> branched.
>     >>
>     >
>     > deprecated features do not be to be removed just after the trunk is
>     > opened for the next release cycle (0.9 here).
>     >
>     >
>     >> ever have a copy that includes the deprecation warnings.  In other
>     >> words, deprecations are linked to releases, not to "time in trunk".
>     >>
>     >
>     > Indeed - but I think that we should let the deprecation be in place
>     > for as long as possible in the source code repository.
>     >
>     >
>
>
>     OK.  It might be a couple more days before I can make the
>     reversions and
>     deprecations, but I'll get them in before the beta release on June 6.
>
> The revised schedule said June 3.

Argh, so it did, and still does.  OK, I'll still try to get the changes 
done by the June 3 beta.

Warren



> Next time I'll write out the months, dd/mm vs mm/dd is obviously not 
> so clear.
>
> If you are still in a cleaning mood, in io there is a lot of stuff you 
> are allowed to remove. The 0.7.0 release notes say:
>
> Several functions in ``scipy.io <http://scipy.io>`` have been 
> deprecated and will be
> removed in the 0.8.0 release including ``npfile``, ``save``, ``load``,
> ``create_module``, ``create_shelf``, ``objload``, ``objsave``,
> ``fopen``, ``read_array``, ``write_array``, ``fread``, ``fwrite``,
> ``bswap``, ``packbits``, ``unpackbits``, and ``convert_objectarray``.
> Some of these functions have been replaced by NumPy's raw reading and
> writing capabilities, memory-mapping capabilities, or array methods.
> Others have been moved from SciPy to NumPy, since basic array reading
> and writing capability is now handled by NumPy.
>
> Cheers,
> Ralf
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From charlesr.harris at gmail.com  Mon May 31 20:35:30 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 18:35:30 -0600
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C0453A0.4020105@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com>
	<AANLkTikrBpYabstlTRv_GLc7wsTUNxU2nv1F6z0A6ofG@mail.gmail.com>
	<4C0453A0.4020105@enthought.com>
Message-ID: <AANLkTim5V26WftEHG87Oipp4QQP_7w0BKHeRw2LL193k@mail.gmail.com>

On Mon, May 31, 2010 at 6:26 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Ralf Gommers wrote:
> >
> >
> > On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser
> > <warren.weckesser at enthought.com
> > <mailto:warren.weckesser at enthought.com>> wrote:
> >
> >     David Cournapeau wrote:
> >     > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
> >     > <warren.weckesser at enthought.com
> >     <mailto:warren.weckesser at enthought.com>> wrote:
> >     >
> >     >> David Cournapeau wrote:
> >     >>
> >     >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
> >     >>> <warren.weckesser at enthought.com
> >     <mailto:warren.weckesser at enthought.com>> wrote:
> >     >>>
> >     >>>
> >     >>>
> >     >>>
> >     >>>> What I would like to do is leave trunk as it is, and after 0.8
> is
> >     >>>> branched, make the appropriate changes in the branch to
> >     follow the
> >     >>>> deprecation policy.  Is that a reasonable approach?
> >     >>>>
> >     >>>>
> >     >>> May I ask why do you want to do that way ?
> >     >>>
> >     >> Because it doesn't look like I will have time to make the
> >     changes before
> >     >> Ralf branches 0.8 tomorrow.
> >     >>
> >     >>
> >     >>>  Putting the deprecation in
> >     >>> the release branch means people tracking trunk will never see
> >     them.
> >     >>>
> >     >>>
> >     >> Good point.    But in case I am misinterpreting what you mean by
> >     >> "tracking trunk" and "see":  I assume this means it is
> >     important to have
> >     >> a record of the deprecation changes in the svn logs, and not
> >     that some
> >     >> who is *using* scipy from trunk also needs to be exposed to the
> >     >> deprecation warning for some minimum amount of time.
> >     >>
> >     >
> >     > actually, I meant both. For example, I often use scipy from
> >     trunk, and
> >     > rarely from releases.  I will never see the deprecation, which
> >     is not
> >     > good.
> >     >
> >     > Also, I think we should generally try to never put things in
> release
> >     > branches, but always backport from trunk (except for branch
> specific
> >     > changes). Having the 0.8 branch created tomorrow does not mean you
> >     > cannot put the changes into trunk, and backport them in 0.8 later -
> >     > deprecation which were already agreed on are the kind of things
> >     which
> >     > can happen after the branching without putting much burden on the
> >     > release process.
> >     >
> >     >
> >     >>  If the changes are
> >     >> made to trunk, then they will be undone immediately after 0.8 is
> >     >> branched.
> >     >>
> >     >
> >     > deprecated features do not be to be removed just after the trunk is
> >     > opened for the next release cycle (0.9 here).
> >     >
> >     >
> >     >> ever have a copy that includes the deprecation warnings.  In other
> >     >> words, deprecations are linked to releases, not to "time in
> trunk".
> >     >>
> >     >
> >     > Indeed - but I think that we should let the deprecation be in place
> >     > for as long as possible in the source code repository.
> >     >
> >     >
> >
> >
> >     OK.  It might be a couple more days before I can make the
> >     reversions and
> >     deprecations, but I'll get them in before the beta release on June 6.
> >
> > The revised schedule said June 3.
>
> Argh, so it did, and still does.  OK, I'll still try to get the changes
> done by the June 3 beta.
>
>
Well, it agrees with the documentation. It's just that I vaguely recall
returning the absolute error in the original. I suppose an error method
could be added. Oh, and I believe someone updated the constants so they are
more recent than 2002, 2005 IIRC, so that should be changed in the
documentation.

<snip>

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/9af0dfd5/attachment.html>

From warren.weckesser at enthought.com  Mon May 31 20:36:57 2010
From: warren.weckesser at enthought.com (Warren Weckesser)
Date: Mon, 31 May 2010 19:36:57 -0500
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <AANLkTin4EwI3ddqExrDhYywT4UOlzab5VPOB2q6NwTHv@mail.gmail.com>
References: <4C012BFE.4090103@enthought.com>	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>	<4C0149EB.8030608@enthought.com>	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>	<4C03F00F.3020806@enthought.com>
	<4C044B0F.4000103@enthought.com>	<AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>	<4C045034.2000205@enthought.com>
	<AANLkTin4EwI3ddqExrDhYywT4UOlzab5VPOB2q6NwTHv@mail.gmail.com>
Message-ID: <4C045629.8020001@enthought.com>

Charles R Harris wrote:
>
>
> On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser 
> <warren.weckesser at enthought.com 
> <mailto:warren.weckesser at enthought.com>> wrote:
>
>     Charles R Harris wrote:
>     >
>     >
>     > On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser
>     > <warren.weckesser at enthought.com
>     <mailto:warren.weckesser at enthought.com>
>     > <mailto:warren.weckesser at enthought.com
>     <mailto:warren.weckesser at enthought.com>>> wrote:
>     >
>     >     Opinion wanted:  codata.find(sub) used to print a list of
>     strings.  A
>     >     while ago, in response to
>     >     http://projects.scipy.org/scipy/ticket/996,  I
>     >     changed it to return the list of strings.  But this is an
>     API change,
>     >     and should follow the deprecation policy.  One way to do
>     this is to
>     >     restore find() to its previous behavior, and deprecate the
>     >     function.  At
>     >     the same time, add a new function, find_string(sub), which
>     returns the
>     >     list of strings.  What do you think?
>     >
>     >
>     > I wouldn't worry about this one, both have the effect of
>     printing out
>     > on the screen. Where is the absolute error though?
>     >
>
>     Well, I will worry about it, just not very much.  Think of it as an
>     exercise in the proper implementation of the deprecation policy--a
>     tiny
>     case study.  Trivial, but with educational value. :)
>
>     What do you mean by "the absolute error"?
>
>
> codata.precision returns the relative error. Perhaps I am mistaken, 
> but I thought the data was published with the absolute error. Both are 
> useful, of course.
>


It looks like the absolute error is in the strings, in the "uncertainty" 
column.  The original author(s) would have to answer your question about 
the precision() function.  I only touched a couple lines in the find() 
function. 

Warren


> Chuck
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>   



From charlesr.harris at gmail.com  Mon May 31 20:46:57 2010
From: charlesr.harris at gmail.com (Charles R Harris)
Date: Mon, 31 May 2010 18:46:57 -0600
Subject: [SciPy-Dev] Mea culpa: deprecation and API changes
In-Reply-To: <4C045629.8020001@enthought.com>
References: <4C012BFE.4090103@enthought.com>
	<AANLkTinBtUuoCiviONCfBgPKO6_9ViPmPmb805WmRjnH@mail.gmail.com>
	<4C0149EB.8030608@enthought.com>
	<AANLkTime2NfLT9W2Q5cboyHwgXZ7v3aBPRPU-xInlYmL@mail.gmail.com>
	<4C03F00F.3020806@enthought.com> <4C044B0F.4000103@enthought.com>
	<AANLkTimsqfw14rIyC3W8C6OsIBahftsugKA0bEYysC1C@mail.gmail.com>
	<4C045034.2000205@enthought.com>
	<AANLkTin4EwI3ddqExrDhYywT4UOlzab5VPOB2q6NwTHv@mail.gmail.com>
	<4C045629.8020001@enthought.com>
Message-ID: <AANLkTimf4mRur_obLJ6zdyYEBy0AaBkNV1n8lvTmK0dJ@mail.gmail.com>

On Mon, May 31, 2010 at 6:36 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Charles R Harris wrote:
> >
> >
> > On Mon, May 31, 2010 at 6:11 PM, Warren Weckesser
> > <warren.weckesser at enthought.com
> > <mailto:warren.weckesser at enthought.com>> wrote:
> >
> >     Charles R Harris wrote:
> >     >
> >     >
> >     > On Mon, May 31, 2010 at 5:49 PM, Warren Weckesser
> >     > <warren.weckesser at enthought.com
> >     <mailto:warren.weckesser at enthought.com>
> >     > <mailto:warren.weckesser at enthought.com
> >     <mailto:warren.weckesser at enthought.com>>> wrote:
> >     >
> >     >     Opinion wanted:  codata.find(sub) used to print a list of
> >     strings.  A
> >     >     while ago, in response to
> >     >     http://projects.scipy.org/scipy/ticket/996,  I
> >     >     changed it to return the list of strings.  But this is an
> >     API change,
> >     >     and should follow the deprecation policy.  One way to do
> >     this is to
> >     >     restore find() to its previous behavior, and deprecate the
> >     >     function.  At
> >     >     the same time, add a new function, find_string(sub), which
> >     returns the
> >     >     list of strings.  What do you think?
> >     >
> >     >
> >     > I wouldn't worry about this one, both have the effect of
> >     printing out
> >     > on the screen. Where is the absolute error though?
> >     >
> >
> >     Well, I will worry about it, just not very much.  Think of it as an
> >     exercise in the proper implementation of the deprecation policy--a
> >     tiny
> >     case study.  Trivial, but with educational value. :)
> >
> >     What do you mean by "the absolute error"?
> >
> >
> > codata.precision returns the relative error. Perhaps I am mistaken,
> > but I thought the data was published with the absolute error. Both are
> > useful, of course.
> >
>
>
> It looks like the absolute error is in the strings, in the "uncertainty"
> column.  The original author(s) would have to answer your question about
> the precision() function.  I only touched a couple lines in the find()
> function.
>
>
I was the original author and sent it to the list as an email attachment. I
have no idea when it actually ended up in scipy, but it was several years
later and I didn't know it was there until recently ;)

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/be8768b3/attachment.html>

From david at silveregg.co.jp  Mon May 31 21:09:33 2010
From: david at silveregg.co.jp (David)
Date: Tue, 01 Jun 2010 10:09:33 +0900
Subject: [SciPy-Dev] Scipy archive on PyPI
In-Reply-To: <AANLkTikch7lzbB_IzHHn4a-NjaRHJDmE1PHmV5fv6wP_@mail.gmail.com>
References: <201005311655.53741.ce@vejnar.eu>
	<AANLkTikch7lzbB_IzHHn4a-NjaRHJDmE1PHmV5fv6wP_@mail.gmail.com>
Message-ID: <4C045DCD.1080503@silveregg.co.jp>

On 06/01/2010 12:15 AM, Ralf Gommers wrote:
>
>
> On Mon, May 31, 2010 at 10:55 PM, Charles Vejnar <ce at vejnar.eu
> <mailto:ce at vejnar.eu>> wrote:
>
>     Hi,
>
>     I was trying to install Scipy with easy_install and it seems that
>     downloading
>     from Sourceforge is no longer possible (Sourceforge no longer gives
>     a direct
>     link to the .tar.gz file) which makes the install fail.
>
>     Would it be possible to always upload the latest Scipy tarball to PyPI ?
>
> It's possible, but because that encourages the use of easy_install/pip
> it would probably give more problems than that it helps. Just today
> there was a thread on numpy-discussion about pip failing and standard
> "python setup.py install" fixing the problem. easy_install is just as
> problematic as pip, if not more so.

Unfortunately, people will always use those half broken tools. I think 
we should at least put the tarballs - I also used to put a simple 
executable (result of bdist_wininst) so that easy_install numpy works on 
windows.

cheers,

David


From d.l.goldsmith at gmail.com  Mon May 31 21:11:49 2010
From: d.l.goldsmith at gmail.com (David Goldsmith)
Date: Mon, 31 May 2010 18:11:49 -0700
Subject: [SciPy-Dev] Addition of a Q+A page to the SciPy side of the Wiki
Message-ID: <AANLkTikj7uIHg-XDSUQ-RCI1PSyj9oXCEJfb6MILBvnl@mail.gmail.com>

Hi!  In conjunction with noting/codifying the conclusion that the docstrings
of the distribution classes (and their instances) in stats.distributions
should not have their docstrings edited (for now in the case of the classes,
ever in the case of the instances), I added a separate Q+A
page<http://docs.scipy.org/scipy/Questions+Answers/>to the SciPy side
of the Wiki.  The way I've set it up, the new page should
be used only for SciPy-specific doc Q+A; NumPy and truly generic Q+A should
continue to go on the NumPy Q+A
page<http://docs.scipy.org/numpy/Questions+Answers/>(but I'm not
married to this arrangement: if someone has strong objections,
we can figure out something else).

DG

-- 
Mathematician: noun, someone who disavows certainty when their uncertainty
set is non-empty, even if that set has measure zero.

Hope: noun, that delusive spirit which escaped Pandora's jar and, with her
lies, prevents mankind from committing a general suicide.  (As interpreted
by Robert Graves)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/a3ba668e/attachment.html>

From matthew.brett at gmail.com  Mon May 31 22:09:02 2010
From: matthew.brett at gmail.com (Matthew Brett)
Date: Mon, 31 May 2010 19:09:02 -0700
Subject: [SciPy-Dev] Development process (was: scipy.stats)
In-Reply-To: <AANLkTimLpSyE7np5BqSKQSmvdBQzimSkCXxg_5ZkHKbS@mail.gmail.com>
References: <AANLkTin58vCwfm71xW3Mi319zq4cAPw5o6xzAPBgFDsX@mail.gmail.com>
	<AANLkTimLpSyE7np5BqSKQSmvdBQzimSkCXxg_5ZkHKbS@mail.gmail.com>
Message-ID: <AANLkTilisJT7naCrpZnb5vqcRNWILtBqkQYx8vh8wmhA@mail.gmail.com>

Hi David,

> I'm sure you mean (for it's the nature of this list, is it not, that we all
> have free rein to be as diplomatic, or not, as we wish) something along the
> lines of: if you tone it down a bit and make it less personal, i.e., be a
> bit more 'diplomatic,' then people are more likely to take you seriously.

Sorry - I should have replied to the earlier thread after starting this one.

I think that is indeed Charles' point, that the best thing to do, is
to identify the general problem, where the problem does not start with
'if only X would not ...'  but is more on the lines of 'there must be
a problem in our process because the following things happen fairly
often ... '

That's what I am trying to do with this thread.   I think we have
structural problem in organization, where it is not clear what the
process for code maintenance is.  I think many people believe that we
need such a process, but, given we do not have one, it is inevitable
that things like this (significant portions of untested code suddenly
appearing in trunk) are going to happen.

What we need is a ) agreement that there is problem and b) an idea of
how to go forward.

I think it's also obvious that that conversation has to happen in
public and on record so we can all have our say and agree.   I'm sure
it's possible to do that.

And - Travis (sorry - I am sure you are doing more enjoyable things
for Memorial day) - of course it's essential that you join in with and
/ or lead that conversation.

See y'all,

Matthew