remove reference to value/error when unwrapping outcome

[graingert]

No description provided.

[TeamSpen210]

This might need to be a new method for backwards compatibility, since the attributes are public, users would be able to still read them after unwrapping. Unless we're fine with that breaking change.

[graingert]

could just call it InvalidatingOutcome, InvalidatingError and InvalidatingValue

[TeamSpen210]

A parallel class hierarchy seems problematic, they'd be incompatible with the current ones. More thinking like unwrap_and_clear(), that's all we need.

[CoolCat467]

Would using a weak reference not be acceptable?

[graingert]

Would using a weak reference not be acceptable?

I think that would be more complicated and it would be odd that unwrapped values are sometimes there sometimes not and not everything can be weakref'd

[richardsheridan]

I'm +1 on "just delete the attribute on unwrap". It's understandable and minimal and the only issue is backwards compatibility, so I'd say slap a unwrap_and_clear() method on version 1.4.0 and make a 2.0.0 release for the cleaner implementation to free more users from refcycles.

[richardsheridan]

Can this be Error(<AlreadyUsed>)?

[richardsheridan]

Can we use descriptors to transmute any late access to self.error or self.value directly to AlreadyUsedError?

[graingert]

Maybe __getattr__?

[TeamSpen210]

Make them private attributes, add a property?

[RazerM]

I'm -1 on deleting public attributes during unwrap. I don't like that accessing an attribute/property may raise, but if we go that route then I'd much prefer AlreadyUsedError over AttributeError.

The way I've always used outcome is to only .unwrap() or .send(), so I would be fine with an outcome 2.0 that doesn't have the attributes, but I know Trio does use them.