Change the initializer style

[konstin]

The first commit simplifies the initializers by making them take a value instead of a function. This essentially means removing ||.

The second commit is more opinionated in that it removes py.init[_mut|_ref](...), meaning that you need to call Py::new[_ref|_mut](py, ...). The reason is that this decouples code (the gil token shouldn't be bound to what Py<T> does) and that it makes more apparent that we're actually instantiating a Py<T> here.

I've also discovered that PyRawObject::init never actually returns an error, so I made it infallible (as in it can only fail with a panic/segfault).

Eventually I'd like to make calling in consturctors Py::new unnecessary through into_object, which would also remove the Ok() wrapping introduced in commit two.

[kngwyu]

LGTM

[kngwyu]

Just a nit, but it looks redundant spaces

[konstin]

Thanks, fixed

[kngwyu]

The first commit simplifies the initializers by making them take a value instead of a function. This essentially means removing ||

👍 for this change. Since we don't have PyToken now, there's no reason to use closure here.

The second commit is more opinionated in that it removes py.init[_mut|_ref](...)

I've also discovered that PyRawObject::init never actually returns an error, so I made it infallible

Also 👍

Eventually I'd like to make calling in consturctors Py::new unnecessary through into_object, which would also remove the Ok() wrapping introduced in commit two.

It looks we can allow users to define fn __new__(obj: &PyRawObject) { by just changing proc macro code 🤔
Isn't it enough?

[konstin]

It looks we can allow users to define fn __new__(obj: &PyRawObject) { by just changing proc macro code thinking
Isn't it enough?

Eventually, I'd like to allow writing idiomatic rust style new function, .e.g.:

#[pyo3]
impl Coordinate {
    #[pyo3(constructor)]
    fn new(x: isize, y: isize) -> Self {
        Coordinate { x, y }
    }
}

I know that this is technically possible because I've implemented it in a wrapper, but there's still a bit missing in pyo3 to properly support that.

[konstin]

The tests are currently failing, that's why I've cherry picked two working commits into individual pull requests

[konstin]

The 3.5 fails due to a travis hiccup, otherwise ci is passing