JuliaPy / JuliaPy/PyCall.jl

RFC: Lazier and more interface-based conversion

Abierto
#617 16 comentarios 10 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
Julia
Estrellas
1.5k
Forks
186
Métricas de merge de PR
Sin PR fusionados en 30 d

Descripción

Rather than trying to convert and copy values between Python and Julia, I propose to:

1. Enhance `pyjlwrap` and implement most of [Python data model](https://docs.python.org/3/reference/datamodel.html) such that virtually all Julia values are usable with `pyjlwrap`. For example, we can translate `getindex` to `__getitem__` etc. such that we can use an `AbstractArray` without translating it to a Numpy array. We can also implement `__array__` in Julia side to make `numpy.asarray` fast.

2. Restrict automatic conversion to Julia types which supports ("practically") lossless round-trip (Julia -> Python -> Julia). Maybe something like:

```julia
Union{
Nothing,
Integer,
NpyNumber, # Int64, Float16, Float32, Float64, ...
Array{<: NpyNumber},
String,
Dates.AbstractTime, # or maybe only the concrete subtypes
IO, # ditto
}
```

Here is a reference implementation that shows this approach works: https://github.com/tkf/PyBase.jl

It would solve, e.g.,:
https://github.com/JuliaPy/PyCall.jl/issues/11
https://github.com/JuliaPy/PyCall.jl/issues/175
https://github.com/JuliaPy/PyCall.jl/issues/507
https://github.com/JuliaPy/PyCall.jl/issues/555
https://github.com/JuliaPy/PyCall.jl/issues/616
https://github.com/JuliaPy/PyPlot.jl/issues/391
https://github.com/JuliaPy/PyPlot.jl/issues/400
https://github.com/JuliaPy/pyjulia/issues/122
https://github.com/JuliaPy/pyjulia/issues/123
https://github.com/JuliaDiffEq/diffeqpy/issues/21

There are many details that can be refined (e.g., rather than using a single Python class, maybe define a few base class? Or even create Python class on-demand?) but first I'd like to know if it is a reasonable direction for PyCall.jl.

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Línea de trabajo

Start by reviewing the existing pyjlwrap approach and the linked PyBase.jl reference implementation, then compare them with the listed conversion-related issues. Done means establishing whether the proposed interface-based conversion direction is suitable for PyCall.jl and refining its scope before implementation.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
julia, python
Área
developer-experience, tooling
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Bastante claro
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.