Deprecate NPY_CHAR #2801

Open
rgommers opened this Issue Dec 9, 2012 · 22 comments

Projects

None yet

6 participants

@rgommers
Member
rgommers commented Dec 9, 2012

This broke ABI compatibility in 1.6.x. Should be deprecated and removed, see http://projects.scipy.org/numpy/ticket/2228

@certik
Contributor
certik commented Dec 14, 2012

@rgommers, how do I deprecate it? In the release notes? Should this be then removed from master but kept in the 1.7 branch? How exactly should this be removed from the master branch? Just removing it from the NPY_TYPES enum?

Thanks for any tips here.

P.S. Where is the github issue corresponding to the ticket 2228? I was not able to find it. I thought all issues were migrated to github...

@rgommers
Member

The Trac tickets with numbers higher than 2225 or so don't have Github equivalents. Trac still has to be made read-only, then the last tickets should be migrated.

Deprecation should be noted in the release notes. It would also be good to use NPY_NO_DEPRECATED_API if possible to generate compiler warnings. See http://docs.scipy.org/doc/numpy-dev/reference/c-api.deprecations.html. Disclaimer: I haven't checked if and how that would work with NPY_CHAR exactly.

@njsmith
Member
njsmith commented Dec 15, 2012

It's extremely difficult to get a compiler warning out of use of an enum. I guess we could exploit the C compiler extensions for deprecations in some complicated way -- maybe give the enum a different name like NPY_CHAR_REAL and then

static const int NPY_CHAR = NPY_CHAR_REAL UGLY_COMPILER_SPECIFIC_DEPRECATION_MACRO;

?

If we've already broken this multiple times and the only code that anyone can find that uses it is unmaintained, then maybe we should just remove it... no-one who actually has NPY_CHAR-using code is going to see the warnings anyway, or bother setting NPY_NO_DEPRECATED_API... that's an opt-in thing for diligent maintainers.

@rgommers
Member

@njsmith I agree that it's not worth spending a lot of effort on. Deprecating in the release notes for 1.7 and removing it for 1.8 should be OK too.

@certik
Contributor
certik commented Dec 15, 2012

@rgommers, can you please review the PR I just sent?

@njsmith
Member
njsmith commented Dec 15, 2012

So after that PR gets merged, the other thing to do is to get a PR to remove NPY_CHAR entirely from master?

@rgommers
Member

Indeed. Let's give that some time though, usually it's not a good idea to rip something out right after deprecating it. I'll change the Milestone for this issue to 1.8.

@certik
Contributor
certik commented Dec 15, 2012

Thanks!

@nouiz nouiz pushed a commit to nouiz/numpy that referenced this issue Dec 17, 2012
@certik certik DOC: Deprecate NPY_CHAR in release notes
Fixes gh-2801.
06973ed
@njsmith
Member
njsmith commented Mar 6, 2013

Time to rip this out of master!

@charris
Member
charris commented Mar 6, 2013

+1

@njsmith
Member
njsmith commented Apr 11, 2013

I looked at this but swiftly got confused. (Perhaps because I have no idea what NPY_CHAR actually is.) Specifically:

  • What's the relation between NPY_CHAR and NPY_CHARLTR? I suppose both should be removed?
  • What do we want to do about f2py? From numpy/f2py/capi_maps.py:
    c2capi_map={  # ...
            'string':'NPY_CHAR', # f2py 2e is not ready for NPY_STRING (must set itemisize etc)
            #'string':'NPY_STRING'

I suppose we could just remove it and see who screams, but someone here might have a better idea of what would happen if we tried...

@rgommers
Member

@pearu could you comment on the f2py question above?

@pearu
Contributor
pearu commented Apr 15, 2013

Current f2py users certainly use NPY_CHAR as character array arguments are quite common in Fortran world.
Removing NPY_CHAR without updating f2py to use NPY_STRING will break the code of those users when upgrading numpy.

To wrap Fortran character arrays, f2py uses NPY_CHAR because at the time of developing f2py, numpy did not have NPY_STRING. Now that NPY_STRING exists, f2py should use it. In fact, it would make wrapping Fortran character arrays to Python much more natural. Currently, f2py users must play a little bit to get hang of how to manage character array arguments.

Implementing NPY_STRING support has been in my TODO list for years. Unfortunately due to the lack of time as well as more cumbersome development cycle of numpy [1], I had to postpone this task to future again and again. I'll try to locate some time and update f2py to use NPY_STRING.

[1] "It's me, not you". In past it was much easier to fix small bugs or develop some feature in numpy.f2py than nowadays, as committing patches was straightforward with subversion. I use git rarely and each time I spend more time to commit patches (due to my git ignorance) than developing a particular patch. I have two options: learn git or create a svn repo of latest numpy and develop f2py from there. The latter would be quickest for me to get things done.

@rgommers
Member

@pearu thanks for the explanation. If it helps you get this done, I'm happy to take your svn repo commits or emailed patches and apply them.

@certik
Contributor
certik commented Apr 15, 2013

Hi @pearu! I think it's a great investment to learn git. But if you prefer subversion, you can use subversion with github easily: https://github.com/blog/1178-collaborating-on-github-with-subversion

@pearu
Contributor
pearu commented Apr 21, 2013

Thanks, Certik, for the hint. However, the suggested workflow does not work with numpy. For instance, I cannot commit a newly created branch (it appears to be forbidden). I'll look other options..

@pearu
Contributor
pearu commented Apr 21, 2013

Ok, I was able to get svn working with github using my numpy fork. I'll let you know when its ready for pull.

@njsmith
Member
njsmith commented Apr 25, 2013

Guess we'll probably have to bump this to 1.9.

@charris
Member
charris commented Feb 21, 2014

@pearu Any progress?

@charris charris added the Deprecate label Feb 21, 2014
@charris charris modified the milestone: 1.10 blockers, 1.9 blockers May 5, 2014
@charris
Member
charris commented May 5, 2014

Moving up to 1.10 blockers.

@charris
Member
charris commented Jun 21, 2015

Moving up to 1.11.

@charris charris modified the milestone: 1.11 blockers, 1.10 blockers Jun 21, 2015
@auvipy
auvipy commented Mar 26, 2016

is this deprecated yet? if not how to deprecate a numpy feature? i'm aware with django internals only

@rgommers rgommers modified the milestone: 1.12.0 release Feb 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment