Georg Brandl

I'm in favor or the non-panicking variant - the case of unhashable objects is one of those instances where everything works perfectly in tests, and then somebody passes an unexpected...

> Where is this function useful? Can it do things Python::with_gil can't? If yes, then we have to accept that people are sometimes forced to use this function, in which...

> I'm concerned about: > We deprecate this. > An user ports over their code from using the deprecated api. > They hit some corner case where Python::with_gil doesn't work....

I feel like I've figured out the solution to this once already, but I don't remember where :( The tuple (Subclass, Baseclass) *should* be possible to convert to a PyObject...

> But this seems like a weird thing to use inheritance for I disagree. It's very common in Python to use subclasses for what we use an enum in Rust.

> I've thought about exactly this in the past. To allow safely converting `Py` to `Py` we would need to guarantee that: > > * `Base` is the first field...

I can't reproduce the latest report; the example given above compiles fine with 0.10 if I make the `#[new]` unconditional, but the other attributes remain conditional. It does not compile...

I'm not sure how to resolve this. We can of course look into `cfg_attr` and ignore it while processing attributes, but that is only correct when the condition is as...

> I don't know if we can "resolve" `cfg_attr` at macro evaluation time, but I guess we can check if the `cfg_attr` on the method is the same as the...

> Oh, darn. But the other ones still present? Yes, that's the problem. I quickly checked with a serde `derive(Deserialize)` and an inner `serde` attribute, and that worked. So either...