On Sun, Feb 5, 2012 at 12:24 AM, Mark Wiebe wrote:

On Sat, Feb 4, 2012 at 8:07 AM, Ralf Gommers wrote:

...

On Wed, Dec 28, 2011 at 2:58 PM, Ralf Gommers < ralf.gommers@googlemail.com> wrote:

...

Hi,

I'm having some trouble cleaning up tests to deal with these two deprecations:

DeprecationWarning: Setting NumPy dtype names is deprecated, the dtype will become immutable in a future version DeprecationWarning: DType strings 'O4' and 'O8' are deprecated because they are platform specific. Use 'O' instead

They seem fairly invasive, judged by the test noise in both numpy and scipy. Record arrays rely on setting dtype names. There are tests for picking and the buffer protocol that generate warnings for O4/O8. Can anyone comment on the necessity of these deprecations and how to deal with them?

Anyone? This is important for the 1.7.0 release.

Also, I don't recall this being discussed. If I'm wrong please point me to the discussion, otherwise some discussion/explanation is in order I think.

I've made a pull request for the O4/O8 issue. This one is an obvious bug, and there was no way to fix the bug without breaking backwards compatibility, so I used deprecation as a mechanism to fix it. Read the pull request here:

https://github.com/numpy/numpy/pull/193

The names issue is a bit trickier. There has been some back and forth in some tickets, and I recall some discussion on the mailing list, but that may be long ago and without clear resolution. That this should be changed is however very clear to me, because NumPy is violating a definition in the Python documentation of what rules hashable objects should obey. The trouble is that there isn't a convenience API written yet to replace the usage of that mutability. Perhaps the thing to do is comment out the deprecation warning in the source code, and reintroduce it in 1.8 along with a replacement API appropriate for immutable dtypes?

That's a good plan. Thanks for the PRs.

Ralf

Fortunately that's not the case. All that Mark is advocating is not allowing changing the *itself* in place. You are still free to change the dtype of the array in order to change the field names without making a data copy. Travis -- Travis Oliphant (on a mobile) 512-826-7480 On Feb 5, 2012, at 9:57 AM, Erin Sheldon wrote:

Excerpts from Mark Wiebe's message of Sat Feb 04 18:24:58 -0500 2012:

...

The names issue is a bit trickier. There has been some back and forth in some tickets, and I recall some discussion on the mailing list, but that may be long ago and without clear resolution. That this should be changed is however very clear to me, because NumPy is violating a definition in the Python documentation of what rules hashable objects should obey. The trouble is that there isn't a convenience API written yet to replace the usage of that mutability. Perhaps the thing to do is comment out the deprecation warning in the source code, and reintroduce it in 1.8 along with a replacement API appropriate for immutable dtypes?

I think we need *some* way to rename fields without making a copy of the data. I often must read from standardized file formats where I can only change the names after the fact. If we deprecate this I would have to make a copy of the data in memory to alter names, which would be prohibitive for large arrays that use >= half the memory.

-e -- Erin Scott Sheldon Brookhaven National Laboratory _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion