Make `to_numpy` conversions consistent with NumPy `dtype`
Les mainteneurs répondent en général sous 1 jour
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 35/100
Piste de recherche
Commencez par l’implémentation liée de to_numpy() dans src/JlWrap/array.jl, puis comparez sa gestion des vecteurs imbriqués avec les exemples NumPy de l’issue. C’est terminé lorsque les tableaux d’entiers imbriqués produisent des valeurs de dtype cohérentes avec NumPy, y compris les cas à deux et trois dimensions décrits ici.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
Moved discussion in #462 into this separate issue.
Other PythonCall issues related to NumPy dtype and Numpy arrays that may be relevant:
- #319
- #439
- #441
- #486
My system details (click to expand)
Julia
julia> versioninfo()
Julia Version 1.12.1
Commit ba1e628ee49 (2025-10-17 13:02 UTC)
Build Info:
Official https://julialang.org release
Platform Info:
OS: Linux (x86_64-linux-gnu)
CPU: 48 × AMD EPYC 7V13 64-Core Processor
WORD_SIZE: 64
LLVM: libLLVM-18.1.7 (ORCJIT, znver3)
GC: Built with stock GC
Threads: 1 default, 1 interactive, 1 GC (on 48 virtual cores)
julia> Pkg.status()
Status `~/temp/Project.toml`
[992eb4ea] CondaPkg v0.2.33
[6099a3de] PythonCall v0.9.28
Python Environment
- python 3.13.9
- numpy 2.3.4
I noticed a difference in how the PythonCall to_numpy() function and NumPy treat property values of dtype as follows:
julia> using PythonCall
julia> Py(rand(10)).to_numpy().dtype
Python: dtype('float64')
julia> Py([[1,2,3], [4,5,6]]).to_numpy().dtype
Python: dtype('O')
I would expect the latter to be dtype('int64') to match Python:
>>> import numpy
>>> a = numpy.array([[1,2,3], [4,5,6]])
>>> a.dtype
dtype('int64')
While Julia does provide Matrix{Int64} and to_numpy() outputs dtype('int64') as I would expect
julia> [1 2 3; 4 5 6] |> typeof
Matrix{Int64} (alias for Array{Int64, 2})
julia> Py([1 2 3; 4 5 6]).to_numpy().dtype
Python: dtype('int64')
I am working on a project where I need to use PythonCall to deal with Vector{Vector{Int64}} instances and changing into Matrix{Int64} is not an option.
In Julia, using PythonCall to_numpy(), it is clear that dtype('int64') is only output for Vector{Int64} not Vector{Vector{Int64}} nor Vector{Vector{Vector{Int64}}} regardless of how many levels of nesting:
julia> Py([1, 2, 3]).to_numpy().dtype
Python: dtype('int64')
julia> Py([[1,2,3], [4,5,6]]).to_numpy().dtype
Python: dtype('O')
julia> Py([[[1,2,3], [4,5,6]], [[7,8,9], [10,11,12]]]).to_numpy().dtype
Python: dtype('O')
Whereas in Python, dtype('int64') is output for all the above:
>>> numpy.array([1, 2, 3]).dtype
dtype('int64')
>>> numpy.array([[1,2,3], [4,5,6]]).dtype
dtype('int64')
>>> numpy.array([[[1,2,3], [4,5,6]], [[7,8,9], [10,11,12]]]).dtype
dtype('int64')
Thus the value of the property .dtype in NumPy is defined based on the innermost elements in the array, whereas in Julia the value of .dtype upon using to_numpy() is not based on the innermost elements (i.e. 1, 2, 3, etc) but on the whole structure containing them (i.e Vector{Int64} for the 2nd array, and Vector{Vector{Int64}} for the 3rd array).
I was expecting the same behaviour from Python's NumPy and the conversions from to_numpy() given by PythonCall, but it turns out the conversion does not agree with NumPy on dtype property values.
- Langage dominant
- Julia
- Étoiles
- 1.1k
- Forks
- 89
- Merge moyen
- 2 j 15 h
- PR mergées (30 j)
- 7
Préparer son environnement
Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de JuliaPy/PythonCall.jl
-
Difficulté 3/5 1-2 jours Accessibilité débutants 55/100
JuliaPy/PythonCall.jl#828 · 7 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 4/5 3-5 jours Accessibilité débutants 48/100
JuliaPy/PythonCall.jl#809 · 2 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
Locking julia dependenciesOuverteenhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 35/100
JuliaPy/PythonCall.jl#805 · 4 commentaires ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 3/5 1-2 jours Accessibilité débutants 68/100
JuliaPy/PythonCall.jl#796 ·
Les mainteneurs répondent en général sous 1 jour
-
enhancement
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 25/100
JuliaPy/PythonCall.jl#790 ·
Les mainteneurs répondent en général sous 1 jour
Toutes les issues de JuliaPy/PythonCall.jl
Issues similaires
-
documentation
Difficulté 2/5 Une demi-journée Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 6 jours
-
broken links in docsOuverte
Difficulté 1/5 Moins d'une heure Accessibilité débutants 78/100
Les mainteneurs répondent en général sous 1 jour
-
bug
Difficulté 2/5 1-3 heures Accessibilité débutants 76/100
JuliaPhysics/BeamletOptics.jl#127 ·
Les mainteneurs répondent en général sous 1 jour
-
Chains resumed from `initial_state` take `num_warmup + 1` warm-up stepsPeut-être pris @thevolatilebit l’a pris il y a 1 jour. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 80/100
TuringLang/AbstractMCMC.jl#220 ·
-
Difficulté 2/5 1-3 heures Accessibilité débutants 75/100
Les mainteneurs répondent en général sous 1 jour