Support other dict types for type.__dict__
On Sat, Feb 25, 2012 at 4:05 PM, Steven D'Aprano <steve@pearwood.info> wrote:
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 Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
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:
This also has implications for people working on making python friendlier for concurrent and parallel programming.
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:
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:
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:
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:
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
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe wrote:
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.
On Mon, Feb 27, 2012 at 07:55:50PM +0100, Victor Stinner wrote:
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.
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
On Mon, Feb 27, 2012 at 11:35 AM, Rob Cliffe <rob.cliffe@btinternet.com> wrote:
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:
This also has implications for people working on making python friendlier for concurrent and parallel programming.
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:
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:
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:
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:
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
On Mon, Feb 27, 2012 at 06:35:57PM +0000, Rob Cliffe wrote:
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.
On Mon, Feb 27, 2012 at 07:55:50PM +0100, Victor Stinner wrote:
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.
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