Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Hrvoje Niksic <hniksic at xemacs.org> writes:

>> Generators aren't slower than hand-coded iterators in *Python*, but
>> that's because Python is a slow language.

> But then it should be slow for both generators and iterators.

Python *is* slow for both generators and iterators.  It's slow for
*everything*, except for cases when you can have most of the work done
within C-coded functions or operations that perform a lot of work
within a single call.  (Or, of course, cases where you are i/o
limited, or whatever.)

>> *Perhaps* there would be some opportunities for more optimization if
>> they had used a less general mechanism.)

> Or if the generators were built into the language and directly
> supported by the compiler.  In some cases implementing a feature is
> *not* a simple case of writing a macro, even in Lisp.  Generators may
> well be one such case.

You can't implement generators in Lisp (with or without macros)
without support for generators within the Lisp implementation.  This
support was provided as "stack groups" on Lisp Machines and as
continuations in Scheme.  Both stack groups and continuations are
slow.  I strongly suspect that if they had provided direct support for
generators, rather than indirectly via stack groups and continuations,
that that support would have been slow as well.

|>oug