bpo-30054: Expose tracemalloc C API#1236
bpo-30054: Expose tracemalloc C API#1236vstinner merged 1 commit intopython:masterpython/cpython:masterfrom vstinner:tracemallocCopy head branch name to clipboard
Conversation
|
@Haypo, thanks for your PR! By analyzing the history of the files in this pull request, we identified @tim-one, @loewis and @mdickinson to be potential reviewers. |
|
cc @jtaylor |
Doc/c-api/memory.rst
Outdated
There was a problem hiding this comment.
:mod:tracemalloc can be used to create a link to the module.
Doc/c-api/memory.rst
Outdated
There was a problem hiding this comment.
Hum, the tracemalloc doc and this doc should mention that the tracemalloc uses the default 0 to trace Python memory allocations.
There was a problem hiding this comment.
I documented the domain 0 in the tracemalloc doc.
|
This looks good to me, but can you add backcompat for the underscore-prefixed versions of |
|
numpy doesn't need the backward compatibility symbols, we just need this merged. |
|
It's true that if you can commit to merging this in the next few days, before numpy makes its next point release, then the backcompat part will become unnecessary. But I don't want to assume that... |
|
@njsmith I like to wait at least two weeks after the first, aka FU, release. It takes that long for the initial bugs to get reported. |
|
Sorry, I don't understand what I should do. We don't provide any warranty on the API stability, _Py functions can be removed between releases, even minor releases. But I can also understand that you don't want to break your CI. |
|
I rebased my PR and addresed my own 2 comments ;-) I documented the default domain (domain 0). |
|
@Haypo: it's not even our CI, it's people who are running their CI on python nightly builds (as recommended here), and are now filing bugs on CPython and numpy. Or are silently giving up on testing cpython nightlies, which is unfortunate because in general I think we like it when people test cpython nightly builds :-). Obviously there can't be any guarantees between 3.x and 3.(x+1), but it is nice to avoid or minimize these problems when we can. In this case: if you are sure you want to merge this for 3.7, then it would be very helpful if you can merge it now-ish; then we'll know not to add any compatibility hacks in the next numpy point release. OTOH if you aren't sure about merging it and want to put it off for later, then it would be helpful to let us know, so we can figure out how to set things up so that it doesn't break things again when you do merge it. |
I added a compatibility layer to pymem.h: |
|
note numpy does not need those compatibility macros, it can already deal with the name change, assuming this gets merged. |
* Make PyTraceMalloc_Track() and PyTraceMalloc_Untrack() functions public (remove the "_" prefix) * Remove the _PyTraceMalloc_domain_t type: use directly unsigned int. * Document methods Note: methods are already tested in test_tracemalloc.
Hum, ok. I removed the compatibility layer since I dislike it, and again, we don't warranty anything on private _PyXXX() functions. |
public (remove the "_" prefix)
int.
Note: methods are already tested in test_tracemalloc.