Adam Olsen <[EMAIL PROTECTED]> wrote: > I need to stress that *only* the new, immutable and "thread-safe > mark-and-sweep" types would be affected by these changes. Everything > else would continue to exist as it did before, and the benchmark > exists to show they can coexist without killing performance.
All the benchmark showed was that checking for a constant in the refcount during in/decrefing, and not garbage collecting those objects, didn't adversely affect performance. As an aside, there's also the ugly bit about being able to guarantee that an object is immutable. I personally mutate Python strings in my C code all the time (long story, not to be discussed here), and if I can do it now, then any malicious or "inventive" person can do the same in this "sandboxed thread" Python "of the future". At least in the case of integers, one could work the tagged integer idea to bypass the freelist issue the Phillip offered, but in general, I don't believe there exists a truely immutable type as long as there is C extensions and/or cTypes. Further, the work to actually implement a new garbage collector for Python in order to handle these 'immutable' types seems to me to be more trouble than it is worth. - Josiah _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
