On Sunday, June 21, 2015 at 8:03:18 AM UTC+5:30, Chris Angelico wrote: > On Sun, Jun 21, 2015 at 11:59 AM, Rustom Mody wrote: > > Recent thread on python ideas > > https://mail.python.org/pipermail/python-ideas/2015-June/034177.html > > > > Since "python's immutable" ≠ "really immutable", we now need a "really > > immutable" > > That's because it requires mutable memory to keep track of reference > counts. In a non-refcountinig Python, strings and integers can be > truly immutable; that thread is suggesting (among other options) > simply storing the refcounts in a separate table. Conceptually, a > string or integer IS immutable, but CPython currently needs to be able > to fiddle with some bookkeeping data about them, in order to pretend > it has plenty of memory. A Python implementation could theoretically > just abandon its strings whenever it's done with them, wasting gobs of > memory in the process, and having them in read-only memory. More > practically, a pure mark-and-sweep GC (such as MicroPython uses) > trades prompt disposal for simple management, and in doing so, > achieves (I think) the same total immutability. > > You have to distinguish between Python (the language) and CPython (the > implementation) here. Python's notion of mutability has nothing to do > with thread safety. You could achieve perfect thread safety for > immutables by simply replicating them into every thread; it'd be > inefficient, but perfectly legal. > > ChrisA
Here is Eric Snow: | Keep in mind that by "immutability" I'm talking about *really* | immutable, perhaps going so far as treating the full memory space | associated with an object as frozen. For instance, we'd have to | ensure that "immutable" Python objects like strings, ints, and tuples | do not change (i.e. via the C API). The contents of involved | tuples/containers would have to be likewise immutable. Even changing | refcounts could be too much, hence the idea of moving refcounts out to | a separate table. | | This level of immutability would be something new to Python. We'll | see if it's necessary. If it isn't too much work it might be a good | idea regardless of the multi-core proposal. Does the second para look like CPython implementation or python-the-language? Also note the 'Even' in the first para. ie Eric is talking of low-level (ie thread-safety, refcounting etc) immutability after the even and higher level semantic immutability before -- https://mail.python.org/mailman/listinfo/python-list
