[Numpy-discussion] dtype repr change?

[Mark Wiebe]

On Wed, Jul 27, 2011 at 5:47 PM, Matthew Brett <matthew.brett at gmail.com>wrote:

> Hi,
>
> On Wed, Jul 27, 2011 at 3:23 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:
> > On Wed, Jul 27, 2011 at 5:07 PM, Gael Varoquaux
> > <gael.varoquaux at normalesup.org> wrote:
> >>
> >> On Wed, Jul 27, 2011 at 04:59:17PM -0500, Mark Wiebe wrote:
> >> >    but ultimately NumPy needs the ability to change its repr and other
> >> >    details like it in order to progress as a software project.
> >>
> >> You have to understand that numpy is the core layer on which people have
> >> build pretty huge scientific codebases with fairly little money flowing
> >> in to support. Any minor change to numpy cause turmoils in labs and is
> >> delt by people (student or researchers) on their spare time. I am not
> >> saying that there should not be any changes to numpy, just that the
> costs
> >> and benefits of these changes need to be weighted carefully. Numpy is
> not
> >> a young and agile project its a foundation library.
> >
> > That's absolutely true. In my opinion, the biggest consequence of this is
> > that great caution needs to be taken during the release process,
> something
> > that Ralf has done a commendable job on.
>
> You seem to be saying that if - say - you - put in some backwards
> incompatibility during development then you are expecting:
>
> a) Not to do anything about this until release time and
> b) That Ralf can clear all that up even though you made the changes.
>

Not at all. What I tried to do is explain the rationale for the change, and
why I believe third party code should not depend on this aspect of the
system. You are free to argue why you believe this point is incorrect, or
why even though it is correct, there are pragmatic reasons why a compromise
solution should be found. Then we can discuss who should do what and figure
out a time frame. That is after all the purpose of the mailing list.

The role Ralf is playing in managing the release process does not involve
doing all the code fixes, it's a group effort. He gets the credit for making
sure everything goes smoothly during the beta and release candidate period,
and that all the loose ends are tied up appropriately.


> I am sure that most people, myself included, are very glad that you
> are trying to improve the numpy internals, and know that that is hard,
> and will cause breakage, from time to time.
>
> On the other hand, if we tell you about breakages or
> incompatibilities, and you tell us 'go fix it yourself', or 'Ralf can
> fix it later' then that can
>
> a) cause bad feeling and
> b) reduce community ownership of the code and
> c) make us anxious about stability.
>

By working with master, you're participating in the development of NumPy.
I'm volunteering as part of this community as much as you are, and I'm doing
things to try and increase participation by giving pointers and suggestions
in bug reports and pull requests. NumPy has a *very* small development team
and a very large user base.

I'm a human being, as are all of us in the NumPy community, and not
everything I do will be perfect. I am, however, for the moment writing a lot
of NumPy code, and there already have been two releases, 1.6.0 and 1.6.1,
with changes authored by me which cut deeper in NumPy than I suspect most
people realize. I would kindly ask that people be patient with and
participate positively in the development process, it is not a
straightforward journey from start to finish.

-Mark


>
> Cheers,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110727/35a16810/attachment.html>