Allow 0..n pymethod blocks without specialization

[konstin]

Surprisingly it's possible and even easy to support multiple impl blocks and even get rid of specialization! This all works thanks to inventory, which uses the ctor binary section to have life-before-main code collect a bunch of instances.

This pull requests uses the doc(hidden) trait inventory::Collect, for which I've opened dtolnay/inventory#5

As a bonus, we also get rid of PyPropMethodsProtocolImpl.

Fixes #302
Relevant for #210

[discosultan]

Does this mean pyo3 will be supported on stable Rust?

[konstin]

Not yet, but that was a major blocker. You can see the remaining blocker by commenting out #![feature(specialization)] in src/lib.rs and running cargo check. And we're of course happy about pull requests fixing some of those errors ;)

[kngwyu]

LGTM

[kngwyu]

Really great PR, thanks.
Looks the outputs of repr changed in examples, e.g. rustapi_module.datetime.TzClass changed to TzClass, which makes travis fail.
Is this intended?

[konstin]

I've removed the module name because currently the module name is whatever module initializes the pyclass, which imho bad because it's not really deterministic. E.g. Adding a module to your module that also adds the class make the class in both modules end up with a different module name.

[konstin]

Eventually, I'd like to have a module name again, but it should be something less volatile.

[athre0z]

Very nice, thanks!

[kngwyu]

@konstin

I've removed the module name because currently the module name is whatever module initializes the pyclass, which imho bad because it's not really deterministic.

I see, 👍 for this.