Generators versus Coroutines
jeff at ccvcorp.com
Tue Aug 17 22:26:46 CEST 2004
Michael Sparks wrote:
>On 17 Aug 2004, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>>No, pure includes C modules included with the interpreter.
>See, this I find a ridiculous assertion. After all the modules that get
>included changes. That means one week one implementation will be viewed as
>impure and the next week pure. That's why I think the whole notion of
>purity is ridiculous.
The included modules will only change with new versions of Python (and
not necessarily then). In practical terms, the need to consider Python
version is more important for minor syntax incompatibilities than for
"pure"-ness considerations, but this definition makes it quite clear
whether something is "pure" Python for any given Python version.
And really, it's not *that* common for major extension packages to start
out independently and then later be incorporated into the Python
standard distribution. There's a few examples, sure... but it's not
like the list of included modules changes much from week to week, as
your objection seems to be implying.
Keep in mind, too, that when people talk about something being "pure"
Python, they're using a practical definition of "pure" rather than a
pure (theoretical) one. ;) It's very practical to say, "This program is
pure Python and runs on version 2.2 or later." That tells me that if
I've got a 2.2 or 2.3 interpreter installed, it'll work on my machine --
I don't have to worry about whether I can find or compile binaries
that'll work for my particular system. I don't care whether or not the
Python standard library ever calls into compiled code, all I care about
is whether *I* need a compiler to install it. (This is especially a
problem on Windows, where compilers are rarely present; *nix machines
usually have gcc (or some other cc) installed by default, but compilers
are not present by default on Windows.)
More information about the Python-list