Greg Ward wrote:
idea; all of a sudden, it's no longer enough to say, "You need Python 1.6" to run this script/use this module, now you need to say, "You need Python 1.6 built with list comprehensions". Ugh.
Andrew Kuchling wrote:
The same argument applies to --with-gc, though, since people might write code that creates cycles and needs GC to run without leaking like a sieve. Making GC optional is still the right solution, though, because its performance effects are still unknown and might be costly.
Greg Wilson writes: I'm really looking forward to recycling my rusty SETL idioms when list comprehensions become part of the "official" release, and to creating graphs in the obvious way if GC ever becomes standard. However, the more variations there are in the "standard" (as opposed to "developer") release, the more expensive (in time and sweat) it is to manage Python at large sites (like Los Alamos). This in turn makes it harder to persuade people that using Python will make their lives easier... Thanks, Greg Footnote: The existence of JPython was one of the arguments in favor of choosing Python for the Software Carpentry project. The fact that JPython and CPython have very different memory management behaviors almost negated that point: as one thirty-year veteran said, "It's no use having code that runs in lots of places if it runs differently in each."