Ideas and progress

[fafhrd91]

1. Seems rust-cpython is on hold right now, no changes, pr hangs without attention for months.
2. as I have now enough experience with rust_cpython py_class implementation, I think it is not good solution. It is separate language within rust. it is very hard to understand and extend.

I work on new py class implementation based on procedural macros and specialization, but that requires rust nightly. should be ready in several days.

[fafhrd91]

new code will look something like this

#[py_class]
struct TestClass {
    data: Cell<bool>
}

#[py_impl]
impl TestClass {

  #[method]
   fn test_method(&self, val: PyObject) {}
}

#[py_impl]
impl PyObjectProtocol for TestClass {

    fn __call__(&self, args: PyTuple, kwargs: PyDict) -> PyResult<> {
    }

   ...
}

#[py_impl]
impl PyAsyncProtocol for TestClass {
   fn __await__(&self) -> PyResult<PyObject> {}
}

[fafhrd91]

@1st1 @asvetlov would you like guys to participate in design work?

[fafhrd91]

py_class may accept parameters,

#[py_class(MyFuture, base=asyncio::Future)]
struct PyFut {}

[fafhrd91]

big question at the moment, how to parse arguments, especially *,

[ohanar]

I agree that rust-cpython's class design isn't ideal. I would prefer to be able to not tie this library to the nightly compiler, if instead this functionality could be done through a custom derive. Something along the lines of the following:

#[derive(PythonClass)]
#[py_methods(my_method(u64, String), my_other_method)]
#[py_traits(PyFunction(PyTuple, ())]
struct MyClass(...);

impl MyClass {
    fn my_method(&self, x: u64) -> PyResult<String> {
        ...
    }
    fn my_other_method(&self) {
        ...
    }
}

impl PyFunction for MyClass {
    fn __call__(&self, y: PyTuple) -> PyResult<()> {
        ...
    }
}

It obviously isn't as nice as what you get with custom attributes (and maybe you could do better than this with some hackery, haven't really thought about it too much), but it should work with stable rust.

[fafhrd91]

problem is how to define special methods, like PyAsyncMethods of PyNumberMethods. you need access to impl block, and you need to enumerate and generate description during macro expansion.

I couldn't find any other way :)

[fafhrd91]

right now, special method implementation is very simple, for example sequence protocol https://github.com/PyO3/PyO3/blob/master/src/class/sequence.rs#L19
btw sequence protocol is not implemented by rust-cpython properly, because of ambiguity of method definitions

[fafhrd91]

added methods and properties implementation

#[class]
struct MyClass {}

#[methods]
impl MyClass {

  fn method(&self, py: Python, arg: PyObject) -> PyResult<()> {
     Ok(())
  }

  #[getter]
  fn get_prop1(&self, py: Python) -> PyResult<PyObject> {...}

  #[setter]
  fn set_prop1(&self, py: Python, value: PyObject) -> PyResult<()> {...}

  #[getter(prop2)]
  fn get_some_prop(&self, py: Python) -> PyResult<PyObject> {...}

  #[setter(prop2)]
  fn set_some_prop(&self, py: Python, value: PyObject) -> PyResult<()> {...}

}

next is "#[class]" macro and argument parsing

[ohanar]

One thing that I like about rust-cpython is that I don't have to manually convert each argument and return result (although I can if I want to). Also, I don't like that there are currently dangling methods when you implement protocols. What about something like this:

trait PySequenceProtocol {
    fn __len__(&self, py: Python) ->Self::Result where Self: PySequenceLenProtocol;
    fn __getitem__(&self, py: Python, key: Self::Key) -> Self::Result where Self: PySequenceGetItemProtocol;
    ...
}

trait PySequenceLenProtocol: PySequenceProtocol {
    type Result: IntoPyResult<Target=usize>; 
}

trait PySequenceGetItemProtocol: PySequenceProtocol {
    type Key: From<isize>; // or maybe something like TryFrom<isize, Err=Self::Result>
    type Result: IntoPyResult;
}

I'll try to prototype something along these lines latter tonight.

[fafhrd91]

arg parser is next after #[class]

regarding dangling methods, those are visible only in rust code, python code does not see unimplemented methods. I don't know how to make method signature explicit and optional at the same time

[fafhrd91]

py_class! is dropped, #[class] is implemented.

[ohanar]

Unfortunately I didn't have as much time as I would like tonight to work on this. I pushed what I did tonight here: 49c3502. The idea is to make rust's trait system do most of the heavy lifting. I haven't touched the attribute macros yet, but all that it should need to do for slotted methods is take something like the following:

#[py_impl]
impl PyMappingProtocol for MyClass {
    fn __len__(&self, py: Python) -> usize {
        ...
    }

    fn __getitem__(&self, py: Python, key: String) -> PyResult<i32> {
        ...
    }
}

And add the following marker trait impls:

impl PyMappingLenProtocol for MyClass {
    type Success = usize;
    type Result = usize;
}

impl PyMappingGetItemProtocol for MyClass {
    type Key = String;
    type Success = i32;
    type Result = PyResult<i32>;
}

After that is done, then some corresponding Impl traits will wrap the methods appropriately, and bundle them up into a PyMappingMethods struct (with null pointers in any slot that hasn't had it's marker trait impl'ed).

I'll try to work more on this over the next couple of days.

[fafhrd91]

That's awesome. I'll play with this idea too

[fafhrd91]

@ohanar
it is not possible partially implement protocol, for example if I need inly __getitem__ method, nothing else, with this approach, I have to implement all methods. imaging something like PyNumberProtocol.
but I really like you idea! maybe we can somehow adjust implementation in attribute macro?