Overloading and? was <RE: Should I prefer an external database>

[Steven Taschuk]

Quoth Andrew Dalke:
> Steven Taschuk:
> > Hm.  I'm not sure I understand what would make such a language not
> > Python.
> 
> I believe apologies are due.  It appears I misread flippancy into
> your response, so this one of mine is now more serious.

On the contrary!  No apology necessary at all, and you correctly
detected flippancy.  (Also see sig.)  I'm just valiantly trying to
bat the nit back.

  [my claim that generators were a bigger change than silly __and__]
> I don't think generators are that large a change.  Pre-generators I
> wrote a lot of code which looked like this
  [iterator example]
> Conceptionally then, I see yield (on top of the iterator protocol)
> as a great way to simplify building an existing idiom.  [...]
> But Python the language did let me get that feel, even in the
> 1.4 days, and adding generators to Python has not affected
> that feel.
  [comparison of silly __and__'s arguments and code blocks]
> Were Python to have code blocks, then it should be applied
> more generally to Python code.  Consider the if/else PEP of
> a couple months ago.  With code blocks, the following would
> be possible
> 
> ifelse(a != 0, 1/a, None)
> 
> which would pass the 1/a and None as independent code
> blocks, to be executed based on the evaluation of a != 0.

Ah, you argue well.

I agree that the canonical use of generators -- to write iterators
-- is merely an improvement of a previously existing idiom, and
does not in itself change the feeling of the language.

But generators' suspend/resume powers let them be used far more
generally.  PEP 288 alludes to some such uses; see also David
Mertz's developerworks articles on using generators to implement
coroutines.

(I have occasionally thought of using Mertz's technique for
*every* kind of call, not merely coroutine calls.  If (say, by
bytecode translation) we turned every call
    foo(*args, **kwargs)
into
    yield foo, args, kwargs
every function would become a generator.  This would allow the
call semantics to be implemented in Python, in what Mertz calls a
scheduler.  You could, for example, build microthreads this way;
if generators could be copied, you could even build continuations!
At least I think so; this is all just a vague idea I have, not
supported by any detailed knowledge of Python internals.  There
are many details to be worked out, e.g., how return values are
provided to the "calling" function, if the call "returns".  (PEP
288 would provide one mechanism.)  There are also efficiency
questions, since e.g. every use of + is potentially a call.)

In other words, the suspend/resume powers of generators open up
all sorts of interesting possibilities which would be difficult to
implement in pre-generator Pythons, and imho these capabilities
can make for significant changes to the feel of the language.

I feel that generators, conceived this broadly, are just as
significant a change as code blocks would be.  (I'm backing down
from my previous claim that they are *more* of a change than the
code blocks implied by the arguments to my silly __and__; now I
claim only that they're of about the same magnitude.)

-- 
Steven Taschuk                           staschuk at telusplanet.net
"I'm always serious, never more so than when I'm being flippant."
                            -- _Look to Windward_, Iain M. Banks