RetroSearch Browse

Thu Nov 25 13:52:44 CET 2010 · https://mail.python.org/pipermail/python-dev/2010-November/106006.html

On 25/11/2010 03:46, Greg Ewing wrote:
> On 25/11/10 12:38, average wrote:
>> Is immutability a general need that should have general solution?
>
Yes, I have sometimes thought this.  Might be nice to have a "mutable" 
attribute that could be read and could be changed from True to False, 
though presumably not vice versa.
> I don't think it really generalizes. Tuples are not just frozen
> lists, for example -- they have a different internal structure
> that's more efficient to create and access.
>
But couldn't they be presented to the Python programmer as a single 
type, with the implementation details hidden "under the hood"?
So
     MyList.__mutable__ = False
would have the same effect as the present
     MyList = tuple(MyList)
This would simplify some code that copes with either list(s) or tuple(s) 
as input data.
One would need syntax for (im)mutable literals, e.g.
     []i    # immutable list (really a tuple).  Bit of a shame that 
"i[]" doesn't work.
or
     []f    # frozen list (same thing)
     []     # mutable list (same as now)
     []m  # alternative syntax for mutable list
This would reduce the overloading on parentheses and avoid having to 
write a tuple of one item as (t,) which often trips up newbies.  It woud 
also avoid one FAQ: Why does Python have separate list and tuple types?  
Also the syntax could be extended, e.g.
     {a,b,c}f      # frozen set with 3 objects
     {p:x,q:y}f  # frozen dictionary with 2 items
     {:}f,  {}f      # (re the thread on set literals) frozen empty 
dictionary and frozen empty set!
Just some thoughts for Python 4.
Best wishes
Rob Cliffe

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2010-November/106006.html below:

[Python-Dev] constant/enum type in stdlib