[Python-ideas] Extending language syntax

Andrew Barnert abarnert at yahoo.com
Tue Nov 12 19:19:10 CET 2013


On Nov 12, 2013, at 6:52, Chris Angelico <rosuav at gmail.com> wrote:

> 
> The reason this might require that the objects be immutable is this:
> When an object is marked as frozen, everything it references can also
> automatically be marked frozen. (By definition, they'll always be in
> use too.) That would only work, though, if the set of objects thus
> referenced doesn't change.
> 
> PI = complex(3.14159)
> sys.freeze(PI)  # should freeze the float value 3.14159
> PI.real = 3.141592653589793
> # awkward

Yes, that's a reasonable extension to the permanent-marking idea. But I'm not sure immutability is as necessary as you think.

For the fork issue, assuming PI is a C object or a slots object, it couldn't be on the never-written page if you went this way, but it would still benefit from not being refcounted.

If you had a permanent complex(3.14159) value, but 3.14159 itself weren't permanent, it would just be a normal float with one refcount that rarely gets copied anywhere. If it does get copied, it gets (atomically) incref'd like normal, but so what?

If you, as the app developer, know that for whatever reason this will be much more common in your app than in the usual case, you can always create the permanent float first, then create the permanent complex out of that value. If you do that, and then later mutate PI to point to a different float, the new float can be permanent or normal and it all works.

If you're forking, then you'd want PI to be immutable (again assuming its a C or slots object); if you're threading and just want the refcount skipping, you'd want a way to get just that.


More information about the Python-ideas mailing list