so it's a bit confusing that the engine has a bunc...
# development
h
so it's a bit confusing that the engine has a bunch of
externs
functions designed to work with `Value`s and `Failure`s, which wrap `PyObject`s, when a lot of the time what we want to do with the result of those functions is get the underlying
PyObject
and do something to it with the cpython api
šŸ‘ 1
`Value`s convert to
PyObjects
fairly straightforwardly, so I think it might be possible to fairly easily convert our
externs
functions to ones dealing directly in cpython types, and then call the appropriate conversion methods at call sites if and when we need `Value`s
on the other hand, a lot of these functions are just wrapping cpython API functions that are also pretty straightforward to use (+ grabbing the gil). so maybe we can get rid of of a lot of them and just use the cpython API directly in call sites
w
yea. i have a todo list item about changing all of the functions in externs to take
AsRef<PyObject>
, which would let you call with either a
PyObject
or a
Value
šŸ‘ 1
the reason to accept both is that converting from
Value
to
PyObject
might involve acquiring the gil and cloning, but viewing a
Value
as a `&PyObject`is very cheap.
h
makes sense.
AsRef<PyObject>
seems like the right choice of type for our APIs around this to accept
w
(ā€¦ having said that, iā€™m not 100% clear on the interaction of
AsRef
and
Deref
ā€¦ one of those.)
h
I think it's
AsRef
,but yeah whichever one makes the typechecker happy
w
Copy code
Alternative answer: you can Deref to only one other type, but you can AsRef to many. So if you have a MyType(String, i32), you could e g implement AsRef for both &String and &i32, but with Deref you'd have to choose one of them.
h
Hey @hundreds-breakfast-49010, have you started this? Iā€™m looking for a small Rust change to make to learn more Rust while knocking off a TODO, even if low priority
h
@hundreds-father-404 I actually did, but only just barely started, so if you want to take it on go ahead