[Numpy-discussion] Going toward time-based release ?

Charles R Harris charlesr.harris@gmail....
Mon May 12 01:39:40 CDT 2008

On Mon, May 12, 2008 at 12:17 AM, Jarrod Millman <millman@berkeley.edu>

> On Sun, May 11, 2008 at 10:42 PM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> > I dunno. I tend to agree with  Mike Ressler that Numpy really shouldn't
> > change very quickly. We can add new features now and then, or move more
> > stuff to type specific functions, but those aren't really user visible.
> Most
> > work, I think, should go into tests, cleaning up the code base and
> > documenting it, and fixing bugs. I also wonder how good a position we
> are in
> > if Travis decides that there are other things he would rather spend his
> time
> > on. Documentation and clean code will help with that. So I really don't
> see
> > that we need much in the way of scheduled releases except to crack the
> whip
> > on us lazy souls who let things ride until we don't have a choice.  If
> we do
> > have scheduled realeases, then I think it will also be necessary to draw
> up
> > a plan for each release, i.e., cleanup  and document ufuncobject.c.src,
> and
> > so on.
> I don't think there is anyone who believes that NumPy should change
> very quickly.  Let's try and drop that discussion.  I am worried that
> if people keep bring up this straw man argument that our users will
> get the impression that we are preparing to break a lot of their code.
>  Besides that changes to MA, there has been very few discussions about
> changing code.  The discussions that have happened have been met with
> numerous comments by several developers that we need to be extremely
> conservative about making API changes.  Even for the matrices
> discussion it seems that very few people are pushing for us to make
> any changes and of those that are most are thinking carefully about
> how to cause as little code breakage as possible.  I know that just
> recently some matrices changes were made that have caused some
> problems, but I am going to rollback those changes.
> I think the main issue is that we need to have more regular releases
> of NumPy and SciPy.  For NumPy you are completely correct that most
> (if not all) of the work should be focused on "tests, cleaning up the
> code base and documenting it, and fixing bugs."  The overriding reason
> that necessitates a 1.2 release at the end of August is the move to
> the nose testing framework.  I feel that this change is extremely
> important and want it to take place as quickly as possible.
> Personally, I don't have any other major changes that I will champion
> getting into 1.2.  The only other major change that has been put forth
> so far is the matrix change, which I personally don't think should
> change the default behavior in the 1.2 release.
> I also really like your suggestion to draw up plans for each release.
> And I would love it if you would be willing to take the lead on
> something for 1.2 like "cleaning up  and documenting
> ufuncobject.c.src."  I would encourage you to start thinking about
> whether you could commit to something like that and, if so, creating a
> ticket for it briefly describing your plan.

As a start, I think we can just reindent all the c code to Python3.0 specs,
and change the style of if and for loops like so:

if (yes) {
else {

And put space around operators in for loops, i.e.,

for (i = 0; i < 10; i++) {

instead of

for (i=0;i<10;i++){whatever;needed;}

and don't do this

if ((a=foo(arg))==0) barf;

Which makes the spot where a gets initialized almost invisible. It is
amazing how much easier the code is to read and understand with these simple
changes. But if we plan tasks for the release, then we also have to assign
people to the task. That is where it gets sticky.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080512/0c6225b7/attachment-0001.html 

More information about the Numpy-discussion mailing list