[Numpy-discussion] Finished maintenance/1.7.x branch

2012-07-17 Thread Travis Oliphant
Hey all, We are going to work on a beta release on the 1.7.x branch.The master is open again for changes for 1.8.x. There will be some work on the 1.7.x branch to fix bugs including bugs that are already reported but have not yet been addressed (like the regression against data-type det

Re: [Numpy-discussion] Pull Requests I'm planning to merge

2012-07-17 Thread Travis Oliphant
On Jul 17, 2012, at 6:48 PM, Nathaniel Smith wrote: > On Tue, Jul 17, 2012 at 9:56 PM, Travis Oliphant wrote: >> >> I would like to merge the following pull requests sometime today: >> >> * 326 -- inplace increment function > > -1, for the reasons stated in the comment thread -- we shouldn't

Re: [Numpy-discussion] "Symbol table not found" compiling numpy from git repository on Windows

2012-07-17 Thread Ondřej Čertík
On Thu, Jan 5, 2012 at 8:22 PM, John Salvatier wrote: > Hello, > > I'm trying to compile numpy on Windows 7 using the command: "python setup.py > config --compiler=mingw32 build" but I get an error about a symbol table not > found. Anyone know how to work around this or what to look into? > > buil

Re: [Numpy-discussion] Pull Requests I'm planning to merge

2012-07-17 Thread Nathaniel Smith
On Tue, Jul 17, 2012 at 9:56 PM, Travis Oliphant wrote: > > I would like to merge the following pull requests sometime today: > > * 326 -- inplace increment function -1, for the reasons stated in the comment thread -- we shouldn't lock ourselves into an ugly API when there's discussion going on a

Re: [Numpy-discussion] Pull Requests I'm planning to merge

2012-07-17 Thread Aron Ahmadia
I (or somebody else) needs to fix 325, Ralf pointed out that I was slightly too aggressive preferring gfortran on vendor operating systems. I think I should be able to fix this in the next couple of hours, I've been delinquent in getting back to it. A On Tue, Jul 17, 2012 at 3:56 PM, Travis Olip

[Numpy-discussion] Pull Requests I'm planning to merge

2012-07-17 Thread Travis Oliphant
I would like to merge the following pull requests sometime today: * 326 -- inplace increment function * 325 -- prefer gfortran on OSX and Linux * 192 -- meshgrid enhancements * 327 -- restore commas and update C-API doc a bit * 352 -- simplifying case for insert and adding tests (#2028) * 350 --

Re: [Numpy-discussion] Would a patch with a function for incrementing an array with advanced indexing be accepted?

2012-07-17 Thread Travis Oliphant
Hey John, Will you be able to clean up the indentation issues for your inplace increment patch today. I would like to include it in NumPy 1.7. Thanks, -Travis On Jul 6, 2012, at 10:37 AM, John Salvatier wrote: > Okay, done ( > https://github.com/jsalvatier/numpy/commit/7d03753e6305dbc878

Re: [Numpy-discussion] py3 datetime woes (was Re: Code Freeze for NumPy 1.7)

2012-07-17 Thread Ralf Gommers
On Mon, Jul 16, 2012 at 3:27 PM, Nathaniel Smith wrote: > On Sun, Jul 15, 2012 at 5:32 PM, Ralf Gommers > wrote: > > Current issues can be seen from the last test log on our Windows XP > buildbot > > (June 29, > > > http://buildbot.scipy.org/builders/Windows_XP_x86/builds/1124/steps/shell_1/logs

Re: [Numpy-discussion] Lazy imports again

2012-07-17 Thread Chris Barker
On Mon, Jul 16, 2012 at 8:37 PM, Travis Oliphant wrote: >--- systems that try to "freeze" Python programs were > particularly annoyed at SciPy's lazy import mechanism. That's ironic to me -- while the solution to a lot of "freezing" problems is to include everything including the kitchen sink --

Re: [Numpy-discussion] Lazy imports again

2012-07-17 Thread Chris Barker
On Mon, Jul 16, 2012 at 2:50 PM, Ralf Gommers wrote: >> Working lazy imports would be useful to have. Ralf is opposed to the idea > Note that my being opposed is because the benefits are smaller than the > cost. If there was a better reason than shaving a couple of extra ms off the > import time

Re: [Numpy-discussion] Lazy imports again

2012-07-17 Thread David Cournapeau
On Tue, Jul 17, 2012 at 1:13 PM, Charles R Harris wrote: > > > On Tue, Jul 17, 2012 at 1:31 AM, David Cournapeau > wrote: >> >> On Mon, Jul 16, 2012 at 5:28 PM, Charles R Harris >> wrote: >> > Hi All, >> > >> > Working lazy imports would be useful to have. Ralf is opposed to the >> > idea >> > b

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

2012-07-17 Thread Pierre GM
On Tuesday, July 17, 2012 at 17:47 , Nathaniel Smith wrote: I guess I still have a small preference for skip_header="comments" over skip_header=True, since the latter is more opaque for no purpose. Also it makes me slightly antsy since skip_header is normally an integer, and True is, in fact, j

Re: [Numpy-discussion] Proposed change in genfromtxt(..., comments='#', names=True) behaviour

2012-07-17 Thread Nathaniel Smith
On Mon, Jul 16, 2012 at 10:39 PM, Pierre GM wrote: > I don't really have any deep issue with `skip_header=True`, besides not > really liking having an argument whose type can vary. But that's only a > matter of personal taste. And yes, we could always check the type… I guess I still have a small

Re: [Numpy-discussion] Lazy imports again

2012-07-17 Thread Charles R Harris
On Tue, Jul 17, 2012 at 1:31 AM, David Cournapeau wrote: > On Mon, Jul 16, 2012 at 5:28 PM, Charles R Harris > wrote: > > Hi All, > > > > Working lazy imports would be useful to have. Ralf is opposed to the idea > > because it caused all sorts of problems on different platforms when it > was > >

Re: [Numpy-discussion] Lazy imports again

2012-07-17 Thread David Cournapeau
On Mon, Jul 16, 2012 at 5:28 PM, Charles R Harris wrote: > Hi All, > > Working lazy imports would be useful to have. Ralf is opposed to the idea > because it caused all sorts of problems on different platforms when it was > tried in scipy. I thought I'd open the topic for discussion so that folks