Numpy: BOGUE: PyArray_BufferConverter n'est pas sûr

Cela est étrange. Je pense que j'aimerais que l'interface de la mémoire tampon spécifie que, tandis que les champs de structure de la mémoire tampon (tels que les foulées, etc.) sont libérés de PyBuffer_Release la mémoire réelle pointée doit appartenir à l'objet d'origine (ce serait résolvez notre problème avec le très ennuyeux _dealloc_cached_buffer_info ). Je pense que c'est l'intention et la vérité, mais ...

Maintenant, cette fonction renvoie un PyArray_Chunk et non un tampon, donc si vous apportez la clarification que je dis ci-dessus, c'est en fait tout à fait correct.

Votre interprétation semble plus raisonnable - peut-être qu'une pull request contre python / cpython serait sage, pour mettre à jour la documentation pour dire aux gens de ne pas implémenter ce que j'ai décrit ci-dessus.

J'allais ouvrir, mais je suis d'abord allé déjeuner: https://bugs.python.org/issue39471 Je peux envisager de proposer des modifications du texte. Si nous pouvons être d'accord sur mon interprétation, nous pouvons nettoyer le code très laid et très lent dans l'implémentation du protocole de tampon (il ralentit actuellement les mathématiques scalaires de 20 +%). (EDIT: Mais je suppose qu'après que Python ait corrigé leur code ArgParse :()

Cela ajoute un peu de clarté, merci - je n'avais pas réalisé que python utilisait la même lecture que bf_releasebuffer que moi.

Merde, j'avais déjà dépassé ça avant (du PEP):

Les exportateurs devront définir une fonction bf_releasebuffer s'ils peuvent réallouer leur mémoire, leurs foulées, leur forme, leurs sous-décalages ou leurs variables de format qu'ils pourraient partager via la structure bufferinfo.

Ce qui se lit comme s'il était valide pour donner au tampon un nouveau morceau de mémoire :(.

Bien que: en regardant l'implémentation de array (python one), tout ce qu'il fait est de l'utiliser pour s'assurer qu'il désactive le redimensionnement si un tampon existe.