Hi all, It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work: - datetime - NA - Bento support My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong. There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think? Cheers, Ralf
I like the idea. Is there resolution to the NA question? -- Travis Oliphant (on a mobile) 512-826-7480 On Dec 5, 2011, at 2:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Mon, Dec 5, 2011 at 9:13 PM, Charles R Harris <charlesr.harris@gmail.com>wrote:
On Mon, Dec 5, 2011 at 1:08 PM, Travis Oliphant <oliphant@enthought.com>wrote:
I like the idea. Is there resolution to the NA question?
No, people still disagree and are likely to do so for years to come with no end in sight. That's why the preview label.
Agreed that it's not resolved, but I think we at least got to the point
where we agreed not to back out the complete missing data additions. So if we clearly say that we keep all options for future API changes open (=preview label), I don't think that the issue should hold up a numpy release indefinitely. Ralf
On Mon, Dec 5, 2011 at 8:43 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible.
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143 Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes Cheers, Ralf What do you all think?
Cheers, Ralf
On Tue, Dec 6, 2011 at 4:11 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Mon, Dec 5, 2011 at 8:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible.
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143
Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes
Cheers, Ralf
What do you all think?
Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This isn't the place for this discussion but we should start talking about building a *high performance* flat file loading solution with good column type inference and sensible defaults, etc. It's clear that loadtable is aiming for highest compatibility-- for example I can read a 2800x30 file in < 50 ms with the read_table / read_csv functions I wrote myself recent in Cython (compared with loadtable taking > 1s as quoted in the pull request), but I don't handle European decimal formats and lots of other sources of unruliness. I personally don't believe in sacrificing an order of magnitude of performance in the 90% case for the 10% case-- so maybe it makes sense to have two functions around: a superfast custom CSV reader for well-behaved data, and a slower, but highly flexible, function like loadtable to fall back on. I think R has two functions read.csv and read.csv2, where read.csv2 is capable of dealing with things like European decimal format. - Wes
On 06.12.2011, at 11:13PM, Wes McKinney wrote:
This isn't the place for this discussion but we should start talking about building a *high performance* flat file loading solution with good column type inference and sensible defaults, etc. It's clear that loadtable is aiming for highest compatibility-- for example I can read a 2800x30 file in < 50 ms with the read_table / read_csv functions I wrote myself recent in Cython (compared with loadtable taking > 1s as quoted in the pull request), but I don't handle European decimal formats and lots of other sources of unruliness. I personally don't believe in sacrificing an order of magnitude of performance in the 90% case for the 10% case-- so maybe it makes sense to have two functions around: a superfast custom CSV reader for well-behaved data, and a slower, but highly flexible, function like loadtable to fall back on. I think R has two functions read.csv and read.csv2, where read.csv2 is capable of dealing with things like European decimal format.
Generally I agree, there's a good case for that, but I have to point out that the 1s time quoted there was with all auto-detection extravaganza turned on. Actually, if I remember the discussions right, in default, single-pass reading mode, it comes even close to genfromtxt and loadtxt (on my machine 150-200 ms for 2800 rows x 30 columns real*8). Originally loadtxt was intended to be that no-frills, fast reader, but in practice it is rarely faster than genfromtxt as the conversion from input strings to Python objects seems to be the bottleneck most of the time. Speeding that up using Cython certainly would be a big gain (and then there also is the request to make loadtxt memory-efficient, which I have failed to follow up on for weeks and weeks…) Cheers, Derek
Le 06/12/2011 23:13, Wes McKinney a écrit :
I think R has two functions read.csv and read.csv2, where read.csv2 is capable of dealing with things like European decimal format.
I may be wrong, but from R's help I understand that read.csv, read.csv2, read.delim, ... are just calls to read.table with different default values (for separtor, decimal sign, ....) This function read.table is indeed pretty flexible (see signature below) Having a dedicated fast function for properly formatted CSV table may be a good idea. But how to define "properly formatted" ... I've seen many tiny variations so I'm not sure ! Now for my personal use, I was not so frustrated by loading performance but rather by NA support, so I wrote my own loadCsv function to get a masked array. It was nor beautiful, neither very efficient, but it does the job ! Best, Pierre read.table &co signatures : read.table(file, header = FALSE, sep = "", quote = "\"'", dec = ".", row.names, col.names, as.is = !stringsAsFactors, na.strings = "NA", colClasses = NA, nrows = -1, skip = 0, check.names = TRUE, fill = !blank.lines.skip, strip.white = FALSE, blank.lines.skip = TRUE, comment.char = "#", allowEscapes = FALSE, flush = FALSE, stringsAsFactors = default.stringsAsFactors(), fileEncoding = "", encoding = "unknown", text) read.csv(file, header = TRUE, sep = ",", quote="\"", dec=".", fill = TRUE, comment.char="", ...) read.csv2(file, header = TRUE, sep = ";", quote="\"", dec=",", fill = TRUE, comment.char="", ...) --------------------------------------------------------- Copy paste from my own dirty "csv toolbox" NA = -9999. def _NA_conv(s): '''convert a string number representation into a float, with a special behaviour for "NA" values : if s=="" or "NA", it returns the key value NA (set to -9999.) ''' if s=='' or s=='NA': return NA else: return float(s) def loadCsv(filename, delimiter=',', usecols=None, skiprows=1): '''wrapper around numpy.loadtxt to load a properly R formatted CSV file with NA values of which the first row should be a header row Returns ------- (headers, data, dataNAs) ''' # 1) Read header headers = [] with open(filename) as f: line = f.readline().strip() headers = line.split(delimiter) if usecols: headers = [headers[i] for i in usecols] # 2) Read converters = None if usecols is not None: converters = dict(zip(usecols, [_NA_conv]*len(usecols))) data = np.loadtxt(filename, delimiter=delimiter, usecols=usecols, skiprows=skiprows, converters = converters ) dataNAs = (data == NA) # Set NAs to zero data[dataNAs] = 0. # Transforms array in "masked array" data = np.ma.masked_array(data, dataNAs) return (headers, data, dataNAs)
On Dec 07, 2011, at 11:24 , Pierre Haessig wrote:
Now for my personal use, I was not so frustrated by loading performance but rather by NA support, so I wrote my own loadCsv function to get a masked array. It was nor beautiful, neither very efficient, but it does the job !
Ever tried to use genfromtxt ?
On Tue, Dec 6, 2011 at 4:13 PM, Wes McKinney <wesmckinn@gmail.com> wrote:
On Tue, Dec 6, 2011 at 4:11 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Mon, Dec 5, 2011 at 8:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible.
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143
Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes
Cheers, Ralf
What do you all think?
Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This isn't the place for this discussion but we should start talking about building a *high performance* flat file loading solution with good column type inference and sensible defaults, etc. It's clear that loadtable is aiming for highest compatibility-- for example I can read a 2800x30 file in < 50 ms with the read_table / read_csv functions I wrote myself recent in Cython (compared with loadtable taking > 1s as quoted in the pull request), but I don't handle European decimal formats and lots of other sources of unruliness. I personally don't believe in sacrificing an order of magnitude of performance in the 90% case for the 10% case-- so maybe it makes sense to have two functions around: a superfast custom CSV reader for well-behaved data, and a slower, but highly flexible, function like loadtable to fall back on. I think R has two functions read.csv and read.csv2, where read.csv2 is capable of dealing with things like European decimal format.
- Wes _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I do not agree with loadtable request simply because not wanting to have functions that do virtually the same thing - as the comments on the pull request (and Chris's email on 'Fast Reading of ASCII files'). I would like to see a valid user space justification for including it because just using regex's is not a suitable justification (but I agree it is a interesting feature): If loadtable will be a complete replacement for genfromtxt then there needs a plan towards supporting all the features of genfromtxt like 'skip_footer' and then genfromtxt needs to be set on the path to be depreciated. If loadtable is an intermediate between loadttxt and genfromtxt, then loadtable needs to be clear exactly what loadtable does not do that genfromtxt does (anything that loadtable does and genfromtxt does not do, should be filed as bug against genfromtxt). Knowing the case makes it easier to provide help by directing users to the appropriate function and which function should have bug reports against. For example, loadtxt requires 'Each row in the text file must have the same number of values' so one can direct a user to genfromtxt for that case rather than filing a bug report against loadtxt. I am also somewhat concerned regarding the NA object because of the limited implementation available. For example, numpy.dot is not implemented. Also there appears to be no plan to increase the implementation across numpy or support it long term. So while I have no problem with it being included, I do think there must be a serious commitment to having it fully supporting in the near future as well as providing a suitable long term roadmap. Otherwise it will just be a problematic code dump that will be difficult to support. Bruce
On Wed, Dec 7, 2011 at 8:45 PM, Bruce Southey <bsouthey@gmail.com> wrote:
On Tue, Dec 6, 2011 at 4:13 PM, Wes McKinney <wesmckinn@gmail.com> wrote:
On Tue, Dec 6, 2011 at 4:11 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Mon, Dec 5, 2011 at 8:43 PM, Ralf Gommers <
ralf.gommers@googlemail.com>
wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing
of
1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible.
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143
Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes
Cheers, Ralf
What do you all think?
Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
This isn't the place for this discussion but we should start talking about building a *high performance* flat file loading solution with good column type inference and sensible defaults, etc. It's clear that loadtable is aiming for highest compatibility-- for example I can read a 2800x30 file in < 50 ms with the read_table / read_csv functions I wrote myself recent in Cython (compared with loadtable taking > 1s as quoted in the pull request), but I don't handle European decimal formats and lots of other sources of unruliness. I personally don't believe in sacrificing an order of magnitude of performance in the 90% case for the 10% case-- so maybe it makes sense to have two functions around: a superfast custom CSV reader for well-behaved data, and a slower, but highly flexible, function like loadtable to fall back on. I think R has two functions read.csv and read.csv2, where read.csv2 is capable of dealing with things like European decimal format.
- Wes _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I do not agree with loadtable request simply because not wanting to have functions that do virtually the same thing - as the comments on the pull request (and Chris's email on 'Fast Reading of ASCII files'). I would like to see a valid user space justification for including it because just using regex's is not a suitable justification (but I agree it is a interesting feature):
There's a number of features listed in the pull request message and Chris' first comment, so I won't repeat those here. That it's close to being ready is just my personal impression. There are seven participants in the pull request including Pierre and Derek, who have both done significant work on loadtxt / genfromtxt, and yourself. So loadtable certainly won't be merged without the questions you raise here being resolved.
If loadtable will be a complete replacement for genfromtxt then there needs a plan towards supporting all the features of genfromtxt like 'skip_footer' and then genfromtxt needs to be set on the path to be depreciated. If loadtable is an intermediate between loadttxt and genfromtxt, then loadtable needs to be clear exactly what loadtable does not do that genfromtxt does (anything that loadtable does and genfromtxt does not do, should be filed as bug against genfromtxt).
Knowing the case makes it easier to provide help by directing users to the appropriate function and which function should have bug reports against. For example, loadtxt requires 'Each row in the text file must have the same number of values' so one can direct a user to genfromtxt for that case rather than filing a bug report against loadtxt.
I am also somewhat concerned regarding the NA object because of the limited implementation available. For example, numpy.dot is not implemented. Also there appears to be no plan to increase the implementation across numpy or support it long term.
I have the vague impression that there is such a plan, or at least the intention to support it better over time. But it would be good if someone could spell this out. Ralf
So while I have no problem with it being included, I do think there must be a serious commitment to having it fully supporting in the near future as well as providing a suitable long term roadmap. Otherwise it will just be a problematic code dump that will be difficult to support.
On Tue, Dec 6, 2011 at 22:11, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143
Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes
I'd suggest that, if possible, someone with sufficient knowledge to evaluate it look at ticket #1990 (data truncation from arrays of strings and integers), since it's both potentially dangerous, as well as a new bug introduced between 1.5.1 and 1.6.1. It might be straightforward to fix without too much difficulty, and if so, I think it's probably worth it. My opinion might be unduly influenced by a collaborator having been bitten by this bug recently, and having to throw away and redo a few weeks of calculations and analysis. Ray Jones
On Tue, Dec 6, 2011 at 22:11, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
To be a bit more detailed here, these are the most significant pull requests / patches that I think can be merged with a limited amount of work: meshgrid enhancements: http://projects.scipy.org/numpy/ticket/966 sample_from function: https://github.com/numpy/numpy/pull/151 loadtable function: https://github.com/numpy/numpy/pull/143
Other maintenance things: - un-deprecate putmask - clean up causes of "DType strings 'O4' and 'O8' are deprecated..." - fix failing einsum and polyfit tests - update release notes
I'd suggest that, if possible, someone with sufficient knowledge to evaluate it look at ticket #1990 (data truncation from arrays of strings and integers), since it's both potentially dangerous, as well as a new bug introduced between 1.5.1 and 1.6.1. It might be straightforward to fix without too much difficulty, and if so, I think it's probably worth it.
My opinion might be unduly influenced by a collaborator having been bitten by this bug recently, and having to throw away and redo a few weeks of calculations and analysis.
I wouldn't call that unduly influenced. Regressions should be the nr. 1
On Wed, Dec 7, 2011 at 5:23 PM, Thouis (Ray) Jones <thouis@gmail.com> wrote: priority for a release, so this should certainly be looked at. I've added a 1.7.0 Milestone on Trac and put this ticket under it. If anyone knows of any other regressions, please do the same. Ralf
On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
Sounds reasonable. I'd also like to add some features to the polynomial modules. 1. Improved zero finding with Gaussian quadrature. With the improved zeros and using an expression for Gaussian weights things work well up to degree 100. 2. Small change to the evaluation functions adding a "tensor" keyword and allowing arrays of coefficients. This change allows easy evaluation of tensor products of the polynomials, either on a grid or on a set of points, which is handy for working in two or three dimensions. I think the recent fixes for user types should also go in, but I'd like Mark to review them first. The R like sampling function could also go in, I just had a question about the name 'choice', but if that is an R compatible name I'm OK with it. In fact, I think many of the current pull requests could go in with the addition of a few tests in some cases. I'll fix the ma.polyfit function test sometime this week. Maybe we should have a weekend devoted to getting the current request in. Chuck
Hi Ralf, On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
I'm now thinking that is too optimistic. There are a fair number of tickets that need to be looked at, including some for einsum and the iterator, and I think the number of pull requests needs to be reduced. How about sometime in the beginning of January? Chuck
On Tue, Dec 20, 2011 at 3:18 PM, Charles R Harris <charlesr.harris@gmail.com
wrote:
Hi Ralf,
On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers <ralf.gommers@googlemail.com
wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
I'm now thinking that is too optimistic. There are a fair number of tickets that need to be looked at, including some for einsum and the iterator, and I think the number of pull requests needs to be reduced. How about sometime in the beginning of January?
Yes, it certainly was. Besides the tickets and pull requests, we also need the support for MinGW 4.x that David is looking at. If that goes smoothly then the first week of January may be feasible, otherwise it'll have to be February (I'm traveling for most of Jan). Or someone else has to volunteer to be the release manager for this release. Ralf
On Tue, Dec 20, 2011 at 9:28 PM, Ralf Gommers <ralf.gommers@googlemail.com>wrote:
On Tue, Dec 20, 2011 at 3:18 PM, Charles R Harris < charlesr.harris@gmail.com> wrote:
Hi Ralf,
On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers < ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
I'm now thinking that is too optimistic. There are a fair number of tickets that need to be looked at, including some for einsum and the iterator, and I think the number of pull requests needs to be reduced. How about sometime in the beginning of January?
Yes, it certainly was. Besides the tickets and pull requests, we also need the support for MinGW 4.x that David is looking at. If that goes smoothly then the first week of January may be feasible, otherwise it'll have to be February (I'm traveling for most of Jan). Or someone else has to volunteer to be the release manager for this release.
There isn't really much progress here. Besides a few smaller issues that still need attention, I think the MinGW 4.x issue is a blocker and needs to be resolved. This can be done either by making it work, or deciding to stick with 3.x. In the latter case numpy.datetime should be fixed somehow. For the next three weeks I'm traveling and won't be able to do any work on numpy. I propose to keep master in a state that's (close to being) releasable until the blocker issue is resolved and we can create a 1.7.x branch. Ralf
On Fri, Jan 6, 2012 at 9:15 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 9:28 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 3:18 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi Ralf,
On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the timing of 1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all think?
I'm now thinking that is too optimistic. There are a fair number of tickets that need to be looked at, including some for einsum and the iterator, and I think the number of pull requests needs to be reduced. How about sometime in the beginning of January?
Yes, it certainly was. Besides the tickets and pull requests, we also need the support for MinGW 4.x that David is looking at. If that goes smoothly then the first week of January may be feasible, otherwise it'll have to be February (I'm traveling for most of Jan). Or someone else has to volunteer to be the release manager for this release.
There isn't really much progress here. Besides a few smaller issues that still need attention, I think the MinGW 4.x issue is a blocker and needs to be resolved. This can be done either by making it work, or deciding to stick with 3.x. In the latter case numpy.datetime should be fixed somehow.
For the next three weeks I'm traveling and won't be able to do any work on numpy. I propose to keep master in a state that's (close to being) releasable until the blocker issue is resolved and we can create a 1.7.x branch.
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I think that my ticket 1973 (http://projects.scipy.org/numpy/ticket/1973) "Can not display a masked array containing np.NA values even if masked" that is due to the astype function not handling the NA object is also a blocker. Bruce
On Sat, Jan 7, 2012 at 2:45 AM, Bruce Southey <bsouthey@gmail.com> wrote:
On Fri, Jan 6, 2012 at 9:15 AM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
On Tue, Dec 20, 2011 at 9:28 PM, Ralf Gommers <
wrote:
On Tue, Dec 20, 2011 at 3:18 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi Ralf,
On Mon, Dec 5, 2011 at 12:43 PM, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi all,
It's been a little over 6 months since the release of 1.6.0 and the NA debate has quieted down, so I'd like to ask your opinion on the
timing of
1.7.0. It looks to me like we have a healthy amount of bug fixes and small improvements, plus three larger chucks of work:
- datetime - NA - Bento support
My impression is that both datetime and NA are releasable, but should be labeled "tech preview" or something similar, because they may still see significant changes. Please correct me if I'm wrong.
There's still some maintenance work to do and pull requests to merge, but a beta release by Christmas should be feasible. What do you all
ralf.gommers@googlemail.com> think?
I'm now thinking that is too optimistic. There are a fair number of tickets that need to be looked at, including some for einsum and the iterator, and I think the number of pull requests needs to be reduced. How about sometime in the beginning of January?
Yes, it certainly was. Besides the tickets and pull requests, we also need the support for MinGW 4.x that David is looking at. If that goes smoothly then the first week of January may be feasible, otherwise it'll have to be February (I'm traveling for most of Jan). Or someone else has to volunteer to be the release manager for this release.
There isn't really much progress here. Besides a few smaller issues that still need attention, I think the MinGW 4.x issue is a blocker and needs to be resolved. This can be done either by making it work, or deciding to stick with 3.x. In the latter case numpy.datetime should be fixed somehow.
For the next three weeks I'm traveling and won't be able to do any work on numpy. I propose to keep master in a state that's (close to being) releasable until the blocker issue is resolved and we can create a 1.7.x branch.
Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I think that my ticket 1973 (http://projects.scipy.org/numpy/ticket/1973) "Can not display a masked array containing np.NA values even if masked" that is due to the astype function not handling the NA object is also a blocker.
I've set it to Milestone 1.7.0. This should be done for all tickets that are important for this release, so we can keep track of it.
Ralf
participants (9)
-
Bruce Southey -
Charles R Harris -
Derek Homeier -
Pierre GM -
Pierre Haessig -
Ralf Gommers -
Thouis (Ray) Jones -
Travis Oliphant -
Wes McKinney