<br><br><div class="gmail_quote">On Mon, May 12, 2008 at 12:17 AM, Jarrod Millman &lt;<a href="mailto:millman@berkeley.edu">millman@berkeley.edu</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Sun, May 11, 2008 at 10:42 PM, Charles R Harris<br>
&lt;<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>&gt; wrote:<br>
&gt; I dunno. I tend to agree with &nbsp;Mike Ressler that Numpy really shouldn&#39;t<br>
&gt; change very quickly. We can add new features now and then, or move more<br>
&gt; stuff to type specific functions, but those aren&#39;t really user visible. Most<br>
&gt; work, I think, should go into tests, cleaning up the code base and<br>
&gt; documenting it, and fixing bugs. I also wonder how good a position we are in<br>
&gt; if Travis decides that there are other things he would rather spend his time<br>
&gt; on. Documentation and clean code will help with that. So I really don&#39;t see<br>
&gt; that we need much in the way of scheduled releases except to crack the whip<br>
&gt; on us lazy souls who let things ride until we don&#39;t have a choice. &nbsp;If we do<br>
&gt; have scheduled realeases, then I think it will also be necessary to draw up<br>
&gt; a plan for each release, i.e., cleanup &nbsp;and document ufuncobject.c.src, and<br>
&gt; so on.<br>
<br>
</div>I don&#39;t think there is anyone who believes that NumPy should change<br>
very quickly. &nbsp;Let&#39;s try and drop that discussion. &nbsp;I am worried that<br>
if people keep bring up this straw man argument that our users will<br>
get the impression that we are preparing to break a lot of their code.<br>
&nbsp;Besides that changes to MA, there has been very few discussions about<br>
changing code. &nbsp;The discussions that have happened have been met with<br>
numerous comments by several developers that we need to be extremely<br>
conservative about making API changes. &nbsp;Even for the matrices<br>
discussion it seems that very few people are pushing for us to make<br>
any changes and of those that are most are thinking carefully about<br>
how to cause as little code breakage as possible. &nbsp;I know that just<br>
recently some matrices changes were made that have caused some<br>
problems, but I am going to rollback those changes.<br>
<br>
I think the main issue is that we need to have more regular releases<br>
of NumPy and SciPy. &nbsp;For NumPy you are completely correct that most<br>
(if not all) of the work should be focused on &quot;tests, cleaning up the<br>
code base and documenting it, and fixing bugs.&quot; &nbsp;The overriding reason<br>
that necessitates a 1.2 release at the end of August is the move to<br>
the nose testing framework. &nbsp;I feel that this change is extremely<br>
important and want it to take place as quickly as possible.<br>
Personally, I don&#39;t have any other major changes that I will champion<br>
getting into 1.2. &nbsp;The only other major change that has been put forth<br>
so far is the matrix change, which I personally don&#39;t think should<br>
change the default behavior in the 1.2 release.<br>
<br>
I also really like your suggestion to draw up plans for each release.<br>
And I would love it if you would be willing to take the lead on<br>
something for 1.2 like &quot;cleaning up &nbsp;and documenting<br>
ufuncobject.c.src.&quot; &nbsp;I would encourage you to start thinking about<br>
whether you could commit to something like that and, if so, creating a<br>
ticket for it briefly describing your plan.<br>
</blockquote><div><br>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:<br><br><span style="font-family: courier new,monospace;">if (yes) {</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">} </span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">else {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">}</span><br>
<br>And put space around operators in for loops, i.e.,<br><br><span style="font-family: courier new,monospace;">for (i = 0; i &lt; 10; i++) {</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">&nbsp;&nbsp;&nbsp; whatever;</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">&nbsp;&nbsp;&nbsp; needed;</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">}</span><br style="font-family: courier new,monospace;">
<br>instead of<br><br><span style="font-family: courier new,monospace;">for (i=0;i&lt;10;i++){whatever;needed;}</span><br style="font-family: courier new,monospace;"><br>and don&#39;t do this<br><br><span style="font-family: courier new,monospace;">if ((a=foo(arg))==0)</span><span style="font-family: courier new,monospace;"> barf;<br>
intervening_code;<br>do_stuff_with_a;</span><span style="font-family: courier new,monospace;"></span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;"></span><br>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.<br>
<br>Chuck<br></div><br></div><br>