Support other dict types for type.__dict__
On Sat, Feb 25, 2012 at 4:05 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Ned Batchelder wrote:
The Python answer for people who want read-only data structures has always been, "Don't modify them if you don't want to, and write docs that tell other people not to as well." What are you building that this answer isn't good enough?
That is silly. That alleged "Python answer" is like telling people that they don't need test frameworks or debuggers because the "Python answer" for people wanting to debug their code is not to write buggy code in the first place.
Perhaps a good middle ground for this is to NOT tie it to particular data structures (like tuples vs lists), but abstract it by making an "immutable bit" that is part of the basic Object type. This doesn't give complete security, but does *force* a choice by a human agent to deliberately modify data. (This was actually going to be implemented in a sort of python fork several years ago.) There could be a "mutable?" check that returns True or False. mark Santa Fe, NM
On 27/02/2012 18:32, Mark Janssen wrote:
On Sat, Feb 25, 2012 at 4:05 PM, Steven D'Aprano<steve@pearwood.info> wrote:
Ned Batchelder wrote:
The Python answer for people who want read-only data structures has always been, "Don't modify them if you don't want to, and write docs that tell other people not to as well." What are you building that this answer isn't good enough? That is silly. That alleged "Python answer" is like telling people that they don't need test frameworks or debuggers because the "Python answer" for people wanting to debug their code is not to write buggy code in the first place. Perhaps a good middle ground for this is to NOT tie it to particular data structures (like tuples vs lists), but abstract it by making an "immutable bit" that is part of the basic Object type. This doesn't give complete security, but does *force* a choice by a human agent to deliberately modify data. (This was actually going to be implemented in a sort of python fork several years ago.) There could be a "mutable?" check that returns True or False.
mark Santa Fe, NM _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
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.
On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@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.... m
On Mon, 27 Feb 2012 11:45:45 -0700 Mark Janssen <dreamingforward@gmail.com> wrote:
On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@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.).
This also has implications for people working on making python friendlier for concurrent and parallel programming.
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....
Ok, you said "non-mutable attributes" in the first paragraph. That to me implies that the object bound to that attribute can't be changed. This is different from the attribute being bound to an immutable object, which this paragraph implies. Which do you want here? <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On Mon, Feb 27, 2012 at 11:45 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@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. -eric
On Mon, Feb 27, 2012 at 12:18 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Mon, Feb 27, 2012 at 11:45 AM, Mark Janssen <dreamingforward@gmail.com> wrote:
On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@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
On Tue, Feb 28, 2012 at 9:48 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
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.
Folks, before retreading this ground, please make sure to review the relevant past history and decide what (if anything) has changed since Barry proposed the freeze protocol 5 years ago and the PEP was rejected: http://www.python.org/dev/peps/pep-0351/ While hypergeneralisation of this behaviour is tempting, it really isn't a solid abstraction. It's better to make use case specific design decisions that handle all the corner cases relating to mutable vs immutable variants of *particular* container types. The issues you have to consider when converting a list to a tuple are not the same as those that exist when converting bytearray to bytes or a set to a frozenset. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Feb 27, 2012 at 5:26 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Tue, Feb 28, 2012 at 9:48 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
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.
Folks, before retreading this ground, please make sure to review the relevant past history and decide what (if anything) has changed since Barry proposed the freeze protocol 5 years ago and the PEP was rejected: http://www.python.org/dev/peps/pep-0351/
While hypergeneralisation of this behaviour is tempting, it really isn't a solid abstraction. It's better to make use case specific design decisions that handle all the corner cases relating to mutable vs immutable variants of *particular* container types. The issues you have to consider when converting a list to a tuple are not the same as those that exist when converting bytearray to bytes or a set to a frozenset.
Point taken. :) I knew I'd heard the idea somewhere. I appreciate how Raymond reacts here: http://mail.python.org/pipermail/python-dev/2006-February/060802.html and how Greg Ewing responds here: http://mail.python.org/pipermail/python-dev/2006-February/060822.html My point was that an __immutable__ flag was not a good idea. However, I agree that the generic protocol is likewise inadvisable because it fosters a generic design approach where a generic one is not appropriate. -eric
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.
If a tuple is just an immutable list it will become worse with regards to performance and memory space. ~Ethan~
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe 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.
The main difference between lists and tuples is not mutability but usage: lists are for a (unknown) number of similar items (a list of messages, e.g.), tuples are for a (known) number of different items at fixed positions (an address is a tuple of (country, city, street address), for example). Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
2012/2/27 Oleg Broytman <phd@phdru.name>:
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe 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.
The main difference between lists and tuples is not mutability but usage: lists are for a (unknown) number of similar items (a list of messages, e.g.), tuples are for a (known) number of different items at fixed positions (an address is a tuple of (country, city, street address), for example).
And tuple doesn't have append, extend, remove, ... methods. Victor
On Mon, Feb 27, 2012 at 07:55:50PM +0100, Victor Stinner wrote:
2012/2/27 Oleg Broytman <phd@phdru.name>:
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe 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.
The main difference between lists and tuples is not mutability but usage: lists are for a (unknown) number of similar items (a list of messages, e.g.), tuples are for a (known) number of different items at fixed positions (an address is a tuple of (country, city, street address), for example).
And tuple doesn't have append, extend, remove, ... methods.
Tuples are *also* read only, but being read only lists is not their main purpose. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
2012/2/27 Oleg Broytman<phd@phdru.name>:
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe 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. The main difference between lists and tuples is not mutability but usage: lists are for a (unknown) number of similar items (a list of messages, e.g.), tuples are for a (known) number of different items at fixed positions (an address is a tuple of (country, city, street address), for example). And tuple doesn't have append, extend, remove, ... methods. Tuples are *also* read only, but being read only lists is not their
On Mon, Feb 27, 2012 at 07:55:50PM +0100, Victor Stinner wrote: main purpose.
Oleg. With respect, I think you are thinking too narrowly, conditioned by familiar usage. Items of a list do not have to be similar (there is nothing in the language that implies that). And tuples are often - conceptually - extended, even though it actually has to be done by building a new tuple - Python even allows you to write tuple1 += tuple2 A unified type would have "mutating" methods such as append - it's just
On 27/02/2012 21:53, Oleg Broytman wrote: that they would raise an error if the object's flag (however it was implemented) defined it as immutable. I visualised an actual object attribute, e.g. __mutable__, that could be set to a boolean value. But having __mutable__() and __immutable__() methods as suggested by Eric is an alternative. And there may well be others. Rob Cliffe
participants (8)
-
Eric Snow -
Ethan Furman -
Mark Janssen -
Mike Meyer -
Nick Coghlan -
Oleg Broytman -
Rob Cliffe -
Victor Stinner