The goal with this iteration of the Entity class is to move persistence of the txspace universe into a relational database. Until now, I had always been trying to figure out ways to avoid requiring verb developers to be able to understand Deferreds.

However, if we treat the txspace development environment as a 'new' one (i.e., not trying to be so standard Pythonic), we could standardize on using inlineCallbacks to decorate the function template that verb code is inserted into.

Better yet, it may be possible to derive a function from inlineCallbacks that could allow for far more control of verb code, since doing anything useful would require yielding to a Deferred. At this point, the inlineCallbacks-derived generator could potentially stop iteration for various reasons (ran too long, verb 'killed', etc).

OTOH, you could still do this:

l = []
while(True):
        l.append('durrrr...')

And that's not going to be good for anybody.

---

Also, what if entities could be presented as:

def look(ctx):
        # look verb

def say(ctx):
        # say verb

contents = {
        'candle'        : get('candle'),
}

parent = get('class_player')
acl = [
        'allow owner everything',
        'allow wizard everything',
]

# etc, etc

This format would be far more useful for big projects, but the existing interface should remain for casual browsing and non-programmers.

Care would have to be taken with respect to what is output for users with varying levels of access, and what is done with the submitted source.

Is it still necessary to use the non-Pythonic approach (e.g., obj.set_parent() instead of obj.parent = ...)?