submit_iteration should not send a message on a plain yield

[mdickinson]

Currently a yield expression in a generator submitted to submit_iteration serves two purposes:

• it sends a message (which could be a status message, a partial result, progress information, or whatever the user wants) to the corresponding future
• it provides a point at which cancellation is checked

However, there's more overhead in the message sending than in the cancellation check. It may make sense not to send any message on a plain yield (or on a yield None, which is indistinguishable at Python level), and only send messages for a non-None expression in a statement of the form yield expression.

This would be a backwards compatibility break. The recommendation for users who want to react to a yield even when that yield contains no additional information would be to use yield True.

[mdickinson]

This would be a good first issue for anyone who wants to get their feet wet with Traits Futures.

[mdickinson]

See the last comment on #236:

Closing. This doesn't seem like the right way to go, partly because of the backwards compatibility break, partly because wanting to receive all values (None or not) from a background iteration seems like a genuine use-case that we shouldn't break, and partly because using submit_iteration when what you want is an interruptible background call already seems like a strained non-obvious API, and doesn't allow users to easily express the intent.

Instead, I think we want a new submission function submit_interruptible that allows submission of a generator factory (almost always a generator function in practice) representing an interruptible computation, plus whatever other machinery is needed to support that.

[mdickinson]

Not in this release.