I don't see any that *have* to go in, but there are a few that could be included. The most significant is probably the inplace fancy indexing if it is ready. The nanmean etc. functions are not committed yet, but I think they are ready. If the Polynomial import fixes show up, they can go in. There are the usual janitorial things, the release notes need some clean up, the docs need merging, and the HOWTO_RELEASE document needs updating. For datetime64, I think a comment should be added to the release notes that it is still experimental and that changes are expected in 1.9. Hopefully the next release will come out next spring. I think we are also about ready for a 1.7.2 release.

On Thu, Aug 15, 2013 at 10:48 AM, Blake Griffith

wrote:

I would like to have the ufunc overrides in 1.8 if it is possible.

On Thu, Aug 15, 2013 at 9:21 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:

...

I don't see any that *have* to go in, but there are a few that could be included. The most significant is probably the inplace fancy indexing if it is ready. The nanmean etc. functions are not committed yet, but I think they are ready. If the Polynomial import fixes show up, they can go in. There are the usual janitorial things, the release notes need some clean up, the docs need merging, and the HOWTO_RELEASE document needs updating.

For datetime64, I think a comment should be added to the release notes that it is still experimental and that changes are expected in 1.9. Hopefully the next release will come out next spring.

I think we are also about ready for a 1.7.2 release.

What is the status of that? I've been leaving that commit up the Pauli.

Chuck

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 15.08.2013 19:52, Charles R Harris kirjoitti:

On Thu, Aug 15, 2013 at 10:48 AM, Blake Griffith

...

wrote: I would like to have the ufunc overrides in 1.8 if it is possible. [clip] What is the status of that? I've been leaving that commit up the Pauli.

I think the PR itself is getting quite complete and does what the spec promises. However, I think the fact that the change comes this late in the release cycle is sort of a problem. There has not been very much time to test it out "in the wild", so we don't know for sure if we'd like still to tweak something in the API. So I'd either suggest merging the PR labelling this as an experimental API in the docs, or if you think this is still too hasty, leave it for 1.9. The Numpy C code changes themselves are quite simple and localized, so it seems unlikely that they could cause any breakage. Getting it in now would have the advantage that we could also manage to squeeze in the corresponding user-side part inside scipy.sparse for Scipy 0.13.0. - -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIPtiYACgkQ6BQxb7O0pWAllACgiGdzoR6uZK4Y8GcqU1A3p7Dg SoAAnjlFg2NVYS3qzy7KPQ5TSJ+ZUdPU =Xdl7 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 17.08.2013 21:20, Charles R Harris kirjoitti: [clip]

Experimental would be OK if it would help you with Scipy 0.13.0. But if it does go in and is used in 0.13, won't that effectively lock it in until the next scipy/numpy release? That seems a bit dangerous if you think some changes might be warranted. OTOH, the testing might be worth the risk...

My hope is that the next numpy release take much less time than 1.8, which is almost three releases worth of changes.

Ok, it starts to seem that it's a bit late also in the Scipy release schedule to get this in 0.13.0, as Ralf is planning to branch that on next Tuesday. The Numpy interactions may reveal some surprises, so I'd prefer this to cook for a while in the dev version. The best route is probably to postpone until 1.9 and 0.14.0, I think. - -- Pauli Virtanen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIPxCIACgkQ6BQxb7O0pWBU3ACgy4NXXXyQJthIcGPD3GTDKljg G+wAoLVhEiH9bVjxfBswTSAP5fb+Tcsb =rKWa -----END PGP SIGNATURE-----

Hi, On Thu, Aug 15, 2013 at 12:10 PM, Ralf Gommers wrote:

On Thu, Aug 15, 2013 at 3:42 PM, Charles R Harris wrote:

...

Hi All,

I'm thinking of making the 1.8.x branch next Sunday. Any complaints, thoughts?

First thought: thanks a lot for doing this.

I'm afraid I don't understand the discussion on timezones in datetime64, but I have the impression that those who do think it needs an urgent decision and some action for the short term. Is that right, datetimers? If that's so, and there are worthwhile changes that are practical in the next few weeks, it seems reasonable to wait. Best, Matthew

Hi, On Thu, Aug 15, 2013 at 12:28 PM, Charles R Harris wrote:

On Thu, Aug 15, 2013 at 1:22 PM, Matthew Brett wrote:

...

Hi,

On Thu, Aug 15, 2013 at 12:10 PM, Ralf Gommers wrote:

...

On Thu, Aug 15, 2013 at 3:42 PM, Charles R Harris wrote:

...

Hi All,

I'm thinking of making the 1.8.x branch next Sunday. Any complaints, thoughts?

First thought: thanks a lot for doing this.

I'm afraid I don't understand the discussion on timezones in datetime64, but I have the impression that those who do think it needs an urgent decision and some action for the short term. Is that right, datetimers?

If that's so, and there are worthwhile changes that are practical in the next few weeks, it seems reasonable to wait.

My impression is that we will have something for 1.9. If it comes in for 1.8, fine. But I think it is still under development. Hopefully the 1.9 release will come out next spring.

OK - then I guess you are saying it is up you, our datetimer friends, to make a proposal and timetable and implementation, if y'all think it can be done in the next few weeks, Best, Matthew

Hi, On Thu, Aug 15, 2013 at 1:04 PM, Ralf Gommers wrote:

On Thu, Aug 15, 2013 at 9:31 PM, Matthew Brett wrote:

...

Hi,

On Thu, Aug 15, 2013 at 12:28 PM, Charles R Harris wrote:

...

On Thu, Aug 15, 2013 at 1:22 PM, Matthew Brett wrote:

...

Hi,

On Thu, Aug 15, 2013 at 12:10 PM, Ralf Gommers wrote:

...

On Thu, Aug 15, 2013 at 3:42 PM, Charles R Harris wrote:

...

Hi All,

I'm thinking of making the 1.8.x branch next Sunday. Any complaints, thoughts?

First thought: thanks a lot for doing this.

I'm afraid I don't understand the discussion on timezones in datetime64, but I have the impression that those who do think it needs an urgent decision and some action for the short term. Is that right, datetimers?

If that's so, and there are worthwhile changes that are practical in the next few weeks, it seems reasonable to wait.

My impression is that we will have something for 1.9. If it comes in for 1.8, fine. But I think it is still under development. Hopefully the 1.9 release will come out next spring.

OK - then I guess you are saying it is up you, our datetimer friends, to make a proposal and timetable and implementation, if y'all think it can be done in the next few weeks,

My impression: there's a reasonable amount of agreement on what has to be done, but no one has stepped up to do the work. It doesn't look like something that should block a release, because there's not a huge amount of interest and the API is already labeled 'experimental'. So I don't really see an issue in releasing 1.8 with the same behavior as 1.7.

Chris B - are you the point man on this one? What do you think? Cheers, Matthew

On Thu, Aug 15, 2013 at 12:31 PM, Matthew Brett wrote:

...

...

I'm afraid I don't understand the discussion on timezones in datetime64, but I have the impression that those who do think it needs an urgent decision and some action for the short term. Is that right, datetimers?

If that's so, and there are worthwhile changes that are practical in the next few weeks, it seems reasonable to wait.

Well, it's only "urgent" in the sense that there are indeed a couple small changes that would really help, and if we don't use a release to motivate us, when will we it ever get done? But it'll still take someone to do it -- I'm afraid it's out of my depth to do so. There is a chance that Mark W. or Travis O. could do it, but it does seem unlikely that they'll find the time in the next week or two, so I guess we'll put it off, and keep the "experimental" label on there.

...

My impression is that we will have something for 1.9. If it comes in for 1.8, fine.

I sure hope we can at least get the "rip out the ugly default I/O TZ behavior" fix in time for 1.9. Whether something more ambitious can be done, we'll have to see.

OK - then I guess you are saying it is up you, our datetimer friends, to make a proposal and timetable and implementation, if y'all think it can be done in the next few weeks,

Yup -- if anyone wants to pipe up and offer to do it, speak now or forever hold your piece. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov