On 10/7/05, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > 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".
Malicious use is hardly a serious concern. Someone using C code could just as well crash the interpreter. Modifying a python string you just created before you expose it to python code should be fine. If that's not what you're doing.. I'm not sure I want to know *wink* > 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. Maybe.. I'm not convinced. There's a lot of payback IMO. -- Adam Olsen, aka Rhamphoryncus _______________________________________________ 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
