Can't __repr__ broken promise.

[r3m0t]

repr(promises.lazy_proxy(operator.truediv, 2, 0)) gives ZeroDivisionError. I think it would be better to give something like <promises.Proxy (broken: ZeroDivisionError)> in this case. Logging a promise should not error.

Alternatively, promises.safe_apply or promises.safe_repr could be added.

[obriencj]

I need to think about this a bit more. Right now the proxy is intended to always be as transparent as possible -- if you give it work, then any access will deliver and attempt to access the work instead. In the case of something that errors, then the delivery error intentionally is passed upwards. Neither the container nor the proxy have a concept of being broken, they just aren't delivered until the work is successful.

What I could conceivably do is write a function called breakable(w), which wraps the work in a try clause, and either introduces a new type to hold any exception (a BrokenPromise perhaps) or simply returns the exception itself as the actual result.

A safe_deliver(p) function could then be written to provide a similar wrapper behavior, but from the outside of the promise rather than the inside.

A promise_repr(p) (or maybe a log_promise(p) ?) or some such would also possibly be very useful, since you could specifically ask for a representation of the proxy/container without attempting delivery. I definitely see the benefit of such a function.

[obriencj]

commit ac98c7e adds BrokenPromise, breakable, breakable_proxy, breakable_deliver, and promise_repr

[r3m0t]

Thanks @obriencj, that was very fast! I still think repr on a lazy_proxy should never fail because the promise can't be evaluated, but I'll just use breakable_proxy instead.

Part of the problem is that repr(obj.val) can normally fail if Obj.val is a property, but repr(val) can't normally fail. Or in other words, Python isn't naturally a lazy language and laziness and exceptions don't mix.

[obriencj]

As you say, repr of a property can fail, because obj.val triggers evaluation. Since python isn't naturally lazy, and there's no top-level attribute type, I agree you would rarely expect repr(val) to fail. Of course it's still possible, because that is indeed calling val.__repr__(), which could have something go wrong, but it's definitely infrequent.

Part of the point of the proxy type is to "hack" in a lazy evaluation that is as transparent as an attribute accessor tries to be. So it really is as though you performed (as in your example) repr(operator.truediv(2, 0)) directly. [edit:] Of course the problem is that the exception is happening in a different frame, but I haven't figured out a way around that yet.

I didn't want to get into overriding some behavior of the proxy but not others, etc. There are the primitive accessors (is_promise, is_delivered, deliver), but apart from those the proxy is intended to be a ghost. If I could figure out a safe way for it to change type at time of delivery, I'd do that as well. Sadly, I haven't come up with that yet :)