Make `to_numpy` conversions consistent with NumPy `dtype`
Maintainer antworten meist innerhalb von 1 Tag
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Beginne mit der verlinkten to_numpy()-Implementierung in src/JlWrap/array.jl und vergleiche anschließend deren Behandlung verschachtelter Vektoren mit den NumPy-Beispielen im Issue. Erledigt ist die Aufgabe, wenn verschachtelte Integer-Arrays dtype-Werte erzeugen, die mit NumPy übereinstimmen, einschließlich der hier beschriebenen zwei- und dreidimensionalen Fälle.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- Julia
- Sterne
- 1.1k
- Forks
- 89
- Ø Merge
- 2 T. 15 Std.
- Gemergte PRs (30 T.)
- 7
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus JuliaPy/PythonCall.jl
-
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
JuliaPy/PythonCall.jl#828 · 7 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
JuliaPy/PythonCall.jl#809 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
JuliaPy/PythonCall.jl#805 · 4 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 68/100
JuliaPy/PythonCall.jl#796 ·
Maintainer antworten meist innerhalb von 1 Tag
-
enhancement
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 25/100
JuliaPy/PythonCall.jl#790 ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in JuliaPy/PythonCall.jl
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
SciML/DiffEqNoiseProcess.jl#342 ·
-
Broken links in the docsOffen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
oxfordcontrol/COSMO.jl#211 ·
-
documentation
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 65/100
Maintainer antworten meist innerhalb von 6 Tagen