Suggesting a new feature - "Inverse Generators"

[Jordan Rastrick]

Hmmm, I like the terminology consumers better than acceptors.

The ability to have 'full coroutines', or at least more 'coroutiney
behaviour' than is provided by generators alone, was I think what I was
trying to get at with my original idea, although things got a bit
sidetracked by the way I focused on the particular (and not espeically
interesting) example I provided. Another factor I think was that I
restricted Acceptors far too much in the second version by demanding
they receive all their input at once - that meant they weren't much
more interesting than a function taking a generator or the like and
using its output. The ability for them to accept input and resume
execution at any point is an essential part of what would make such a
feature interesting. Maybe if they gave you a callable object, and just
avoided the whole issue of return value all-together, something like

# I wish I could think of a more interesting example
def combineIntoRecords(listToAppend):
accept firstline
# etc
listToAppend.append(record)
# No return value, avoid issues of non-evaluation

recordList = []
combine = combineIntoRecords(recordList)
for line in filterJunk(lines):
combine(line)

This acheives the same result as before, but of course now youre free
to use combine anywhere else in the code if you wanted.

I still think this kind would allow you to do things that can't be done
using the other techniques brought up in this discussion... maybe Terry
or somebody else familiar with Consumers might know a good example?

Anyway this has all been very interesting, and I've learned a lot. I
never really had a clue what Stackless Python was before, and now I
think I have a vague idea of some of the implications. Not to mention
the little tidbit about default argument evaluation. And groupby looks
very interesting.

Thanks everyone for the host of replies, which have all been of an
excellent standard IMO. I only wish being a newbie in other languages
was as much fun as it is in Python

Now to actually finish implementing my text file parser. The only
problem is deciding between the dozens of potential different methods...

 

[Guest]

The ability to have 'full coroutines', or at least more 'coroutiney

behaviour' than is provided by generators alone, was I think what I

was

Jordan,

This is somewhat off-topic, but perhaps you might be interested in
taking a look at the Lua language (http://www.lua.org/). It supports
coroutines, and is similar to Python in that it is a dynamically typed
language with support for a nice associative dictionary-like data
structure. It doesn't cover the same solution space that Python does,
but it is an interesting language to play with.

Phil Schmidt

 

[Oren Tirosh]

Hmmm, I like the terminology consumers better than acceptors.

Here's an implementation of Python consumers using generators:
http://groups.google.co.uk/[email protected]

Oren