[Python-ideas] Support other dict types for type.__dict__

[Eric Snow]

On Mon, Feb 27, 2012 at 12:18 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> On Mon, Feb 27, 2012 at 11:45 AM, Mark Janssen
> <dreamingforward at gmail.com> wrote:
>> On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe at btinternet.com> wrote:
>>> I suggested a "mutable" attribute some time ago.
>>> This could lead to finally doing away with one of Python's FAQs: Why does
>>> python have lists AND tuples?  They could be unified into a single type.
>>> Rob Cliffe.
>>
>> Yeah, that would be cool.  It would force (ok, *allow*) the
>> documenting of any non-mutable attributes (i.e. when they're mutable,
>> and why they're being set immutable, etc.).
>>
>> There an interesting question, then, should the mutable bit be on the
>> Object itself (the whole type) or in each instance....?  There's
>> probably no "provable" or abstract answer to this, but rather just an
>> organization principle to the language....
>
> In contrast to a flag on objects, one alternative is to have a
> __mutable__() method for immutable types and __immutable__() for
> mutable types.  I'd be nervous about being able to make an immutable
> object mutable at an arbitrary moment with the associated effect on
> the hash of the object.

Just to be clear, I meant that __mutable__() would return a mutable
version of the object, of a distinct mutable type, if the object
supported one.  So for a tuple, it would return the corresponding
list.  These would be distinct objects.  Likewise obj.__immutable__()
would return a separate, immutable version of obj.

Such an approach could be applied to lists/tuples, sets/frozensets,
strings/bytearrays, bytes/bytearrays, and any other pairings we
already have.  Unless a frozendict were added as a standard type, dict
would not have a match so an __immutable__() method would not be
added.  In that case, trying to call dict.__immutable__() would be an
AttributeError, as happens now.

-eric