Awesome, thanks for working on this.

I believe this should be a regular DEPRECATE, not DEPRECATE_FUTUREWARNING (since the new behaviour in the future will be an exception, not silently altered results).

Needs a test.

Your tests are failing.

There are test failures here.

@jayvius, would you have time to finish this? This issue is a blocker for the 1.7 release.

Yes, I'm working on addressing all the issues with this pull request by
tomorrow.

On Sun, Dec 16, 2012 at 2:18 PM, Ondřej Čertík notifications@github.comwrote:

@jayvius https://github.com/jayvius, would you have time to finish
this? This issue is a blocker for the 1.7 release.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2797#issuecomment-11422250.

Yes, I'm working on addressing all the issues with this pull request by
tomorrow.

Thanks! I really appreciate your help on this.

After this goes into 1.7 you might want to consider moving the deprecation tests into the new test_deprecation.py module.

I know there are other deprecation tests scattered about too, e.g. for the
diagonal changes - we should probably as a separate change see about
grepping for DeprecationWarning to consolidate them. (Having them in one
place seems useful for reviewing before the next release. Esp. if annotated
with comments about when they were introduced.)
On 17 Dec 2012 17:54, "Charles Harris" notifications@github.com wrote:

After this goes into 1.7 you might want to consider moving the deprecation
tests into the new test_deprecation.py module.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2797#issuecomment-11452097.

Anyone know why 'g12' type would throw a warning on my Macbook but fail to throw a warning on the Travis build server? It seems like 12 shouldn't be a valid size for 'g' regardless of platform.

Don't know why the warning doesn't show up on Python <2.7, but on 2.7 and 3.x it looks like the test will fail anyway unless you run it with python -Wd.

It seems to make it through the tests just fine though on 2.7 and 3.x until
it hits the 'g12' test.

On Mon, Dec 17, 2012 at 1:59 PM, Ralf Gommers notifications@github.comwrote:

Don't know why the warning doesn't show up on Python <2.7, but on 2.7 and
3.x it looks like the test will fail anyway unless you run it with python
-Wd.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2797#issuecomment-11458582.

Ah yes, because in NoseTester there's warnings.filterwarnings('always', category=DeprecationWarning).

Note though that this only works in the maintenance branches, in master it's warnings.filterwarnings('error', category=DeprecationWarning). So if you want to put this in master, you'll need to play with the warning settings.

Thanks Jay for fixing it. Tests still fail, so we need to figure out how to tests this, so that tests don't fail, before we can merge this.

Yeah, sorry about letting this one linger. I still can't figure out why the
test works on my Macbook and fails on the build server. Is it considered
bad practice to commit some debug logging and trigger a new Travis build
with the debug logging?

On Thu, Dec 20, 2012 at 6:36 PM, Ondřej Čertík notifications@github.comwrote:

Thanks Jay for fixing it. Tests still fail, so we need to figure out how
to tests this, so that tests don't fail, before we can merge this.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2797#issuecomment-11598604.

Naw, go for it. Just remember to get rid of the debug logging again before
we merge :-)

On Fri, Dec 21, 2012 at 3:33 PM, Jay Bourque notifications@github.comwrote:

Yeah, sorry about letting this one linger. I still can't figure out why
the
test works on my Macbook and fails on the build server. Is it considered
bad practice to commit some debug logging and trigger a new Travis build
with the debug logging?

On Thu, Dec 20, 2012 at 6:36 PM, Ondřej Čertík notifications@github.comwrote:

Thanks Jay for fixing it. Tests still fail, so we need to figure out how
to tests this, so that tests don't fail, before we can merge this.

—
Reply to this email directly or view it on GitHub<
https://github.com/numpy/numpy/pull/2797#issuecomment-11598604>.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2797#issuecomment-11617000.

Weird...apparently a long double on Travis is 12 bytes. I didn't think that size was all that common.

That issue should be fixed, but now the python 3.1 build is failing on Travis due to an issue with nose. Any ideas?

Travis just dropped support for 3.1... and it looks like instead of, say, for example, not running builds on unsupported python versions, they're just running the build directly against their system py2.7. Which fails because our build script assumes a virtualenv, not a system python.

In short you can ignore this.

@certik - backport away.

@njsmith, this PR was made against 1.7, so it is already backported. This time, we need to forwardport it: #2853.