Release of NumPy

classic Classic list List threaded Threaded
73 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Release of NumPy

Travis Oliphant-5
After the SciPy sprints some useful discussions took place that helped
us all realize that we have made enough changes to the code base that we
will need to call any release from the trunk 1.1

I don't think that is a big problem.   However,  there have also been a
lot of substantial bug fixes that really deserve to be applied against
1.0.4 and released as 1.0.5

So, the question is.  Do we have enough energy in the community to
release the current trunk as 1.1 as well as release 1.0.5 which does not
contain any of the code/api changes, but just the bug fixes?  The answer
will be yes if somebody volunteers to back-port just the bug-fixes to
1.0.4.    I would really like there to be a bug-fix 1.0.5 release if at
all possible.

Best regards,

-Travis



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
On Mon, Apr 14, 2008 at 9:59 PM, Travis E. Oliphant
<[hidden email]> wrote:
>  So, the question is.  Do we have enough energy in the community to
>  release the current trunk as 1.1 as well as release 1.0.5 which does not
>  contain any of the code/api changes, but just the bug fixes?  The answer
>  will be yes if somebody volunteers to back-port just the bug-fixes to
>  1.0.4.    I would really like there to be a bug-fix 1.0.5 release if at
>  all possible.

Personally, I would rather see everyone's effort focused on 1.1 and
the 1.2 (previously referred to as 1.1).  But if anyone is interested
in backporting some of the bug-fixes, I will help coordinate a 1.0.5
release.  For now, I hope to keep everyone focused on the trunk, which
will become 1.1.0 very soon.

I will send out an email fairly soon listing the last things that need
to be done before releasing 1.1.0.  Basically, I would like to have
some testing of the new Windows and Mac binaries.  David C. has all
ready sent out an email asking for help testing the new Window's
binaries.  Chris Burns or I will be sending out an email asking for
help testing the new Universal Mac binaries within the next day.

Thanks,

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Charles R Harris
In reply to this post by Travis Oliphant-5


On Mon, Apr 14, 2008 at 10:59 PM, Travis E. Oliphant <[hidden email]> wrote:
After the SciPy sprints some useful discussions took place that helped
us all realize that we have made enough changes to the code base that we
will need to call any release from the trunk 1.1

I don't think that is a big problem.   However,  there have also been a
lot of substantial bug fixes that really deserve to be applied against
1.0.4 and released as 1.0.5

So, the question is.  Do we have enough energy in the community to
release the current trunk as 1.1 as well as release 1.0.5 which does not
contain any of the code/api changes, but just the bug fixes?  The answer
will be yes if somebody volunteers to back-port just the bug-fixes to
1.0.4.    I would really like there to be a bug-fix 1.0.5 release if at
all possible.

I think we have a long way to go to get to 1.1. What API changes have we made that are so great that we can't release 1.0.5? The only area where I have seen real problems is in masked arrays. My preference would be to release the trunk as 1.0.5, and if not, simply deprecate 1.0.4 and move to 1.1.  I don't think it's worth the time and effort to backport anything.

Chuck



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

cdavid
Charles R Harris wrote:
>
> I think we have a long way to go to get to 1.1. What API changes have
> we made that are so great that we can't release 1.0.5? The only area
> where I have seen real problems is in masked arrays. My preference
> would be to release the trunk as 1.0.5, and if not, simply deprecate
> 1.0.4 and move to 1.1.  I don't think it's worth the time and effort
> to backport anything.

Normally, api versioning does not depend on how big your changes are: if
you break even one function api, you should signal an API break. It
really boils down to conventions: what do you do when you break API ?
For major C/C++ libraries which care about API/ABI stability, this means
a new major version. For python, this means new minor version. For
numpy, it could be new micro version...

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
In reply to this post by Charles R Harris
On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
<[hidden email]> wrote:
> I think we have a long way to go to get to 1.1. What API changes have we
> made that are so great that we can't release 1.0.5? The only area where I
> have seen real problems is in masked arrays. My preference would be to
> release the trunk as 1.0.5, and if not, simply deprecate 1.0.4 and move to
> 1.1.  I don't think it's worth the time and effort to backport anything.

I was originally expecting to release the trunk as 1.0.5, but I just
started worrying that we had been a little too liberal (mea culpa)
with allowing some code changes that were pushing in API breakage and
new features.  Since I think the trunk is fairly stable and we should
release ASAP, I propose to have a very short-lived 1.1 and move to
developing 1.2 as soon as 1.1 is released.  This will also allow us to
"officially" deprecate or warn users about upcoming changes in 1.2 in
the 1.1 release series.

Sorry that I wasn't more careful in watching over the 1.0.5 release
and that we are having to go to a 1.1 release on such short notice.
Again, just to be clear:  This doesn't signify a change in the scope
of the next release, we are just being more honest about the status of
this release.  We could have added more API breakage and features to
this release, if I had noticed what was happening sooner.

Thanks,

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
On Mon, Apr 14, 2008 at 10:28 PM, Jarrod Millman <[hidden email]> wrote:
> On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
>  <[hidden email]> wrote:
>  > I think we have a long way to go to get to 1.1. What API changes have we
>  > made that are so great that we can't release 1.0.5? The only area where I
>  > have seen real problems is in masked arrays. My preference would be to
>  > release the trunk as 1.0.5, and if not, simply deprecate 1.0.4 and move to
>  > 1.1.  I don't think it's worth the time and effort to backport anything.

Also as I was maintaining the release notes for "1.0.5", I started
noticing that we have a fairly extensive list of features/changes for
a microrelease, particularly for such a late microrelease:
http://projects.scipy.org/scipy/numpy/milestone/1.0.5
I would expect most users to expect substantially less changes between
1.0.4 and 1.0.5 than between 1.0.0 and 1.0.2 (or 1.0.3).

This numbering thing is really all about making sure we don't violate
our user's expectations.

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Charles R Harris
In reply to this post by Jarrod Millman


On Mon, Apr 14, 2008 at 11:28 PM, Jarrod Millman <[hidden email]> wrote:
On Mon, Apr 14, 2008 at 10:10 PM, Charles R Harris
<[hidden email]> wrote:
> I think we have a long way to go to get to 1.1. What API changes have we
> made that are so great that we can't release 1.0.5? The only area where I
> have seen real problems is in masked arrays. My preference would be to
> release the trunk as 1.0.5, and if not, simply deprecate 1.0.4 and move to
> 1.1.  I don't think it's worth the time and effort to backport anything.

I was originally expecting to release the trunk as 1.0.5, but I just
started worrying that we had been a little too liberal (mea culpa)
with allowing some code changes that were pushing in API breakage and
new features.  Since I think the trunk is fairly stable and we should
release ASAP, I propose to have a very short-lived 1.1 and move to
developing 1.2 as soon as 1.1 is released.  This will also allow us to
"officially" deprecate or warn users about upcoming changes in 1.2 in
the 1.1 release series.

Let's not rush 1.1, then. I think with another week or two we should be able to settle most of the outstanding bugs and it would be good to do so before getting caught up in planning 1.2.

Chuck



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
On Mon, Apr 14, 2008 at 10:38 PM, Charles R Harris
<[hidden email]> wrote:
> Let's not rush 1.1, then. I think with another week or two we should be able
> to settle most of the outstanding bugs and it would be good to do so before
> getting caught up in planning 1.2.

+1.  I think that we are so close to closing every reported bug that
spending another week or two would be wise.  I also want to have very
stable and easy-to-use binaries for both Windows and Mac for this
release, which we are very close to doing.  Chris has all ready made
MacOS X binaries; he is just cleaning up a few things before asking
for more testing.

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Alan G Isaac
In reply to this post by Charles R Harris
On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
> Let's not rush 1.1, then.

Will matrix behavior change in 1.1, as discussed from time
to time?  Perhaps it just takes a very small change in __getitem__:
<URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>

Cheers,
Alan Isaac



_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
On Mon, Apr 14, 2008 at 10:54 PM, Alan G Isaac <[hidden email]> wrote:
> On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
>  > Let's not rush 1.1, then.
>
>  Will matrix behavior change in 1.1, as discussed from time
>  to time?  Perhaps it just takes a very small change in __getitem__:
>  <URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>

Given that the next release will be 1.1, I think it is reasonable to
include a few additional API breaks.  But I would prefer that we focus
on fixing bugs and not introducing new ones, so I would strongly
encourage everyone to be *very* conservative in adding new features or
API breaks at this point.  Those are just general comments, I don't
have any particular opinion on your specific question.  I would be
interested in what other people think.

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Robert Kern-2
On Tue, Apr 15, 2008 at 1:33 AM, Jarrod Millman <[hidden email]> wrote:

> On Mon, Apr 14, 2008 at 10:54 PM, Alan G Isaac <[hidden email]> wrote:
>  > On Mon, 14 Apr 2008, Charles R Harris apparently wrote:
>  >  > Let's not rush 1.1, then.
>  >
>  >  Will matrix behavior change in 1.1, as discussed from time
>  >  to time?  Perhaps it just takes a very small change in __getitem__:
>  >  <URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>
>
>  Given that the next release will be 1.1, I think it is reasonable to
>  include a few additional API breaks.

-lots. I don't want to break API compatibility again no matter what
version number we bump to, 1.1, 2.0, or 24. It is simply not okay to
do this again and again.

--
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

cdavid
Robert Kern wrote:
>
> -lots. I don't want to break API compatibility again no matter what
> version number we bump to, 1.1, 2.0, or 24. It is simply not okay to
> do this again and again.
>
>  

I didn't dare saying anything, but now that I see I am not the only one,
I can sheepishly say I agree more than 100 %. At some point, we will
really have to stop breaking api every few weeks. That was ok when numpy
was not 1.*, but as numpy will - hopefully - get some bigger traction,
it will just become unmanageable to keep breaking things, users will
hate it.

This is so much more important than import conventions and other details
when you have a large user-base :)

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
In reply to this post by Robert Kern-2
On Mon, Apr 14, 2008 at 11:38 PM, Robert Kern <[hidden email]> wrote:
>  >  Given that the next release will be 1.1, I think it is reasonable to
>  >  include a few additional API breaks.
>
>  -lots. I don't want to break API compatibility again no matter what
>  version number we bump to, 1.1, 2.0, or 24. It is simply not okay to
>  do this again and again.

I didn't mean to sound like I was encouraging API breakage.  I agree
with Robert we need to be extremely careful about breaking the API.
NumPy is a fairly mature project that is depended on by lots and lots
of code.  If we break the API, we better have an extremely good reason
and, even then, we need to minimize it as much as possible.  My main
concern is that when we do break APIs we can't do it in a micro
release like 1.0.5.

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jon Wright
In reply to this post by Alan G Isaac
Alan G Isaac wrote:
>
> Will matrix behavior change in 1.1, as discussed from time
> to time?  Perhaps it just takes a very small change in __getitem__:
> <URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>

Quoting from:
http://mail.python.org/pipermail/python-dev/2008-March/077723.html
"""
Executive summary: Python 2.6 and 3.0 finals are planned for September
3, 2008.
"""

In the event that there really is a valid reason to change the API (much
like serial killers have their own valid reasons for their crimes...).
Why not finalise that perfect API for the python3.0 build, when everyone
is expecting code to change for 3K? Name them numpy3.x.x to match the
python major version.

I bring this up because I'm actually wondering which bits of numpy will
make it into the 3k standard library? Must've already been decided by
now, seeing as 3K is so close to release already. Has anyone tried numpy
on the alpha releases already?

Jon








_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Robert Kern-2
On Tue, Apr 15, 2008 at 2:31 AM, Jon Wright <[hidden email]> wrote:

> Alan G Isaac wrote:
>  >
>  > Will matrix behavior change in 1.1, as discussed from time
>  > to time?  Perhaps it just takes a very small change in __getitem__:
>  > <URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>
>
>  Quoting from:
>  http://mail.python.org/pipermail/python-dev/2008-March/077723.html
>  """
>  Executive summary: Python 2.6 and 3.0 finals are planned for September
>  3, 2008.
>  """
>
>  In the event that there really is a valid reason to change the API (much
>  like serial killers have their own valid reasons for their crimes...).
>  Why not finalise that perfect API for the python3.0 build, when everyone
>  is expecting code to change for 3K? Name them numpy3.x.x to match the
>  python major version.

The Python community has been begging package owners *not* to do this.
That would impose yet another hurdle to the adoption of Python 3.0.

--
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
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Sebastian Haase
On Tue, Apr 15, 2008 at 9:41 AM, Robert Kern <[hidden email]> wrote:

> On Tue, Apr 15, 2008 at 2:31 AM, Jon Wright <[hidden email]> wrote:
>  > Alan G Isaac wrote:
>  >  >
>  >  > Will matrix behavior change in 1.1, as discussed from time
>  >  > to time?  Perhaps it just takes a very small change in __getitem__:
>  >  > <URL:http://www.mail-archive.com/numpy-discussion@.../msg07363.html>
>  >
>  >  Quoting from:
>  >  http://mail.python.org/pipermail/python-dev/2008-March/077723.html
>  >  """
>  >  Executive summary: Python 2.6 and 3.0 finals are planned for September
>  >  3, 2008.
>  >  """
>  >
>  >  In the event that there really is a valid reason to change the API (much
>  >  like serial killers have their own valid reasons for their crimes...).
>  >  Why not finalise that perfect API for the python3.0 build, when everyone
>  >  is expecting code to change for 3K? Name them numpy3.x.x to match the
>  >  python major version.
>
>  The Python community has been begging package owners *not* to do this.
>  That would impose yet another hurdle to the adoption of Python 3.0.
>
>

So, to summarize one more time:
"""
What used to be talked about as "1.1" will now become "1.2" ---
and "1.0.5" will be "1.1"
"""

Did I get this right !?

I'm curious to know _which_ were the changes that break the API. I
thought all additions like "axis=0" were made without breaking the
backwards compatibility. Otherwise it would (should !!!) have been
added as "axis=None".

Please keep in mind that there are a number of these "awkward"
"wrong-default" arguments. I was hoping these would be unified [e.g.
always same default, axis=None]  very soon  -- that is in 1.1.
Also on my list is   N.resize vs. arr.resize, were one fills with
zeros, the other repeats.
{{{
>>> N.resize([1,2,3], 6)
[1 2 3 1 2 3]
>>> a=N.array([1,2,3]);a.resize(6);a
[1 2 3 0 0 0]
}}}
very confusing !! Please speak out !

Regards and thanks you all for the good/hard work !
-Sebastian Haase
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

cdavid
Sebastian Haase wrote:

>
> So, to summarize one more time:
> """
> What used to be talked about as "1.1" will now become "1.2" ---
> and "1.0.5" will be "1.1"
> """
>
> Did I get this right !?
>
> I'm curious to know _which_ were the changes that break the API. I
> thought all additions like "axis=0" were made without breaking the
> backwards compatibility. Otherwise it would (should !!!) have been
> added as "axis=None".

The new masked array has significant different behaviour than the old
one, for once. This may be the biggest change for the formally known as
1.0.5. Personally, I think focusing on version number is wrong: what
matters is API changes/compatibility, and how we handle it. Everything
else is just nitpicking.

>
> Please keep in mind that there are a number of these "awkward"
> "wrong-default" arguments. I was hoping these would be unified [e.g.
> always same default, axis=None]  very soon  -- that is in 1.1.
>

Is this noted somewhere (e.g. is there a ticket for it ?). I think
unifying API is really important, and the only way to do it is to keep
track of those inconsistencies, so that we can decide what to do with them.

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Jarrod Millman
On Tue, Apr 15, 2008 at 12:56 AM, David Cournapeau
<[hidden email]> wrote:
>  > Please keep in mind that there are a number of these "awkward"
>  > "wrong-default" arguments. I was hoping these would be unified [e.g.
>  > always same default, axis=None]  very soon  -- that is in 1.1.
>
>  Is this noted somewhere (e.g. is there a ticket for it ?). I think
>  unifying API is really important, and the only way to do it is to keep
>  track of those inconsistencies, so that we can decide what to do with them.

I agree that unifying the API is really important.  So I agree with
Robert that we need to be extremely conservative in breaking the API.
However, unifying the API is one area that I think could arguably
(depending on the specific case) justify breaking the existing API.

For instance, the 1.1.0 release, which will come out ASAP, introduces
'axis' support for numpy.median().  In 1.1, by default "axis=0" and
then in the 1.2.0 release, which will come out at the end of summer,
"axis=None" by default:
http://scipy.org/scipy/numpy/ticket/558

Another example of a potential API break has been proposed for histogram:
http://projects.scipy.org/pipermail/numpy-discussion/2008-April/032450.html
http://scipy.org/scipy/numpy/ticket/605

If someone could put together a list of instances like these that we
should discuss, it would be extremely useful.  We could potentially
try and put in warnings for functions that we want to modify.  Again
we need to be extremely careful here.  We should avoid breaking our
user's code as much as possible.

However, when our current API is "broken" we should be open to the
possibility that in may need to be fixed.  Functions with anomalous
interfaces seem like a good example of candidates that would be worth
modifying.  However, we need to consider whether the code is so widely
used that modifying it would unacceptable.  Furthermore, I would be
less concerned about modifying the interface to functions, if we can
also include an upgrade script that will automatically fix old code.
So, for example, we could include an upgrade script with 1.2, which
modifies calls to numpy.median() so that 'axis=0'.  That way our users
could upgrade their code to work with NumPy 1.2 by simply running the
upgrade script.

Thanks,

--
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

Sebastian Haase
In reply to this post by cdavid
On Tue, Apr 15, 2008 at 9:56 AM, David Cournapeau
<[hidden email]> wrote:

> Sebastian Haase wrote:
>  >
>  > So, to summarize one more time:
>  > """
>  > What used to be talked about as "1.1" will now become "1.2" ---
>  > and "1.0.5" will be "1.1"
>  > """
>  >
>  > Did I get this right !?
>  >
>  > I'm curious to know _which_ were the changes that break the API. I
>  > thought all additions like "axis=0" were made without breaking the
>  > backwards compatibility. Otherwise it would (should !!!) have been
>  > added as "axis=None".
>
>  The new masked array has significant different behaviour than the old
>  one, for once. This may be the biggest change for the formally known as
>  1.0.5. Personally, I think focusing on version number is wrong: what
>  matters is API changes/compatibility, and how we handle it. Everything
>  else is just nitpicking.
>


How about releasing 1.0.5 without the new masked array,
i.e.
1. put back the old masked array and release as 1.0.5
2. then release 1.1.0 with the new masked array
3. start working on 1.2 by unifying the arguments, "np.resize", and
other things alike.

--Sebastian
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Release of NumPy

cdavid
Sebastian Haase wrote:
>
>
> How about releasing 1.0.5 without the new masked array,
> i.e.
> 1. put back the old masked array and release as 1.0.5

Now that it is done, going back will be a lot of work. It would be great
if someone were willing to do it, but who ?

cheers,

David
_______________________________________________
Numpy-discussion mailing list
[hidden email]
http://projects.scipy.org/mailman/listinfo/numpy-discussion
1234