RE: Making immutable instances

2005-12-01 Thread Rick Wotnaz
Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Was it *really* necessary to send 4 separate emails to reply to four sections of the same email? Good netiquette is to intersperse your comments with quoted sections in a single email. Tim Delaney Good netiquette

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
[EMAIL PROTECTED] writes: Mike Meyer wrote: [EMAIL PROTECTED] writes: Quoting the frequently used term Practicality beats purity. If I have a practical problem/needs now and it solves it, why not use it ? In other words, you have a use case. Cool. Please tell us what it is - at least if

Re: Making immutable instances

2005-12-01 Thread Paul Rubin
Mike Meyer [EMAIL PROTECTED] writes: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. What is the use case for immutable strings? Why shouldn't strings be mutable like they are in Scheme? Generally if I know I don't plan to mutate something, I'd want

RE: Making immutable instances

2005-12-01 Thread Delaney, Timothy (Tim)
Rick Wotnaz wrote: Good netiquette might also suggest quoting what you're replying to, wouldn't you think? Damn - I trimmed [EMAIL PROTECTED] instead of python-list from the To: list. I stuffed up. This one intentionally sent to python-list. Tim Delaney --

Re: Making immutable instances

2005-12-01 Thread Ben Finney
Mike Meyer [EMAIL PROTECTED] wrote: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. Perhaps you missed my release announcement of the 'enum' package that explains why Enum instances are immutable. -- \Hanging one scoundrel, it appears, does

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. What is the use case for immutable strings? Why shouldn't strings be mutable like they are in Scheme? I don't know. Why

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
Ben Finney [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. Perhaps you missed my release announcement of the 'enum' package that explains why Enum instances are immutable. Yes, I did. I

Re: Making immutable instances

2005-12-01 Thread bonono
Mike Meyer wrote: That's not a use case, that's a debugging aid. The same logic applies to adding type declarations, private/public/etc. declerations, and similar BD language features. It's generally considered that it's not a good enough reason for adding those, so it doesn't really

Re: Making immutable instances

2005-12-01 Thread Ben Finney
Mike Meyer [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: Lots of people seem to want immutable instances. Nobody seems to have a use case for them. Perhaps you missed my release announcement of the 'enum' package that explains why Enum

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
[EMAIL PROTECTED] writes: Mike Meyer wrote: That's not a use case, that's a debugging aid. The same logic applies to adding type declarations, private/public/etc. declerations, and similar BD language features. It's generally considered that it's not a good enough reason for adding those, so

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
Ben Finney [EMAIL PROTECTED] writes: Since the values of an enumeration are directly reflected in the values and attributes, Enum instances are immutable to preserve this relationship This justifies making the attributes immutable. But that's old hat - I had that use case last

Re: Making immutable instances

2005-12-01 Thread bonono
Mike Meyer wrote: By design, this is a don't use feature so it would be very hard to find a use case ;-) But I can think of use cases for instances with no mutable attributes, which is another don't use case. If I can do that, those proposing that instances ought to be immutable should be

Re: Making immutable instances

2005-12-01 Thread Alex Martelli
Mike Meyer [EMAIL PROTECTED] wrote: ... This is a problem with OO in general, not with not having immutable instances. You get the same problem if, instead of attaching attributes to your instances, I subclass your class and add the attribute in the subclass (which I can do even if both my

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
[EMAIL PROTECTED] writes: Mike Meyer wrote: By design, this is a don't use feature so it would be very hard to find a use case ;-) But I can think of use cases for instances with no mutable attributes, which is another don't use case. If I can do that, those proposing that instances ought

Re: Making immutable instances

2005-12-01 Thread Ben Finney
Mike Meyer [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] writes: Since the values of an enumeration are directly reflected in the values and attributes, Enum instances are immutable to preserve this relationship This justifies making the attributes immutable. But

Re: Making immutable instances

2005-12-01 Thread Mike Meyer
Ben Finney [EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] writes: Since the values of an enumeration are directly reflected in the values and attributes, Enum instances are immutable to preserve this relationship This justifies

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: Letting the class author declare whether or not the client can add attributes is wrong for the same reasons - and in the same places - that letting the class author declare that the client shouldn't be allowed to

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes: I am puzzled, and could have read what you want wrong. Are you saying you want something like this : a={} a.something = I want to hang my stuff here, outside the intended use of dict Exactly. For a use case, consider calling select.select on lists of file objects.

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: [EMAIL PROTECTED] writes: I am puzzled, and could have read what you want wrong. Are you saying you want something like this : a={} a.something = I want to hang my stuff here, outside the intended use of dict Exactly. For a use case, consider calling select.select

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes: Mike Meyer wrote: [EMAIL PROTECTED] writes: I am puzzled, and could have read what you want wrong. Are you saying you want something like this : a={} a.something = I want to hang my stuff here, outside the intended use of dict Exactly. For a use case,

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: Built-in types don't have a real dictionary. They have a C struct that holds the various methods. The entries in the struct are called slots, hence the __slots__ magic attribute. That __slots__ makes it impossible to add an attribute is documented as an implementation

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes: Well, in this case, would it be simple for the OP that if he wants to disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior. Using it to get that effect is abuse of the feature, and may well quit

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: If the authors go to the length of not allowing it, so be it. They are afterall define it for their use and how someone else will use it don't matter. I take it you never distribute your code, or otherwise expect other people to reuse it? No, distribute when necessary.

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: [EMAIL PROTECTED] writes: Well, in this case, would it be simple for the OP that if he wants to disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior. Using it to get that effect is abuse of the feature,

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: [EMAIL PROTECTED] writes: Well, in this case, would it be simple for the OP that if he wants to disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior. Using it to get that effect is abuse of the feature,

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: And again, *what's the use case*? A number of people have asked why we shouldn't allow this, but none of them been able to come up with a use case better than I think doing that is bad style. oh, that is the usual argument anyway. It is nothing but style, most of the time.

RE: Making immutable instances

2005-11-30 Thread Delaney, Timothy (Tim)
Was it *really* necessary to send 4 separate emails to reply to four sections of the same email? Good netiquette is to intersperse your comments with quoted sections in a single email. Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes: Mike Meyer wrote: [EMAIL PROTECTED] writes: Well, in this case, would it be simple for the OP that if he wants to disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior. Using it to get that effect

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: [EMAIL PROTECTED] writes: Mike Meyer wrote: [EMAIL PROTECTED] writes: Well, in this case, would it be simple for the OP that if he wants to disallow this attaching additional things, just use __slot__. That's *documented* as an implementation-dependent behavior.

Re: Making immutable instances

2005-11-30 Thread Mike Meyer
[EMAIL PROTECTED] writes: Quoting the frequently used term Practicality beats purity. If I have a practical problem/needs now and it solves it, why not use it ? In other words, you have a use case. Cool. Please tell us what it is - at least if it's better than I think that's bad style.

Re: Making immutable instances

2005-11-30 Thread bonono
Mike Meyer wrote: [EMAIL PROTECTED] writes: Quoting the frequently used term Practicality beats purity. If I have a practical problem/needs now and it solves it, why not use it ? In other words, you have a use case. Cool. Please tell us what it is - at least if it's better than I think

Re: Making immutable instances

2005-11-29 Thread Paul Rubin
Mike Meyer [EMAIL PROTECTED] writes: When it was suggested that a facility for doing this be added to the language, I asked for a use case for it. Nobodies come up with a reason for placing such restriction on the client yet. If you've got a use case, I'd be interested in hearing it. I see it

Re: Making immutable instances

2005-11-29 Thread Mike Meyer
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: When it was suggested that a facility for doing this be added to the language, I asked for a use case for it. Nobodies come up with a reason for placing such restriction on the client yet. If you've got a use

Re: Making immutable instances

2005-11-29 Thread Paul Rubin
Mike Meyer [EMAIL PROTECTED] writes: Letting the class author declare whether or not the client can add attributes is wrong for the same reasons - and in the same places - that letting the class author declare that the client shouldn't be allowed to access specific attributes, and so on, is

Re: Making immutable instances

2005-11-29 Thread bonono
Mike Meyer wrote: The thing is, the need for an extra attribute doesn't come from your class, it comes from the client of your class. You can't know if the client code will need that facility or not, so the only choice you know won't be wrong sometime is to always add the mixin. In which

Re: Making immutable instances

2005-11-28 Thread Antoon Pardon
Op 2005-11-26, Steven D'Aprano schreef [EMAIL PROTECTED]: On Thu, 24 Nov 2005 12:55:07 +, Antoon Pardon wrote: Suppose I have the following code. from module import __take_care__ __private_detail__ = ... I now have two variable that are flaged the same way, but they are not. No,

Re: Making immutable instances

2005-11-26 Thread Steven D'Aprano
On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: Hmmm, the class designer didn't want me adding attributes to instances... maybe he had a good reason for that... When it was suggested that a facility for doing this be added to the language, I

Re: Making immutable instances

2005-11-26 Thread Mike Meyer
Steven D'Aprano [EMAIL PROTECTED] writes: On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: If you've got a use case, I'd be interested in hearing it. frozenset perhaps? If it were needed once, it could be needed again. That's not a use case, that's an example. And not a very good one, as

Re: Making immutable instances

2005-11-26 Thread Steven D'Aprano
On Sat, 26 Nov 2005 04:59:59 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: If you've got a use case, I'd be interested in hearing it. frozenset perhaps? If it were needed once, it could be needed again. That's not a

Re: Making immutable instances

2005-11-26 Thread Mike Meyer
Steven D'Aprano [EMAIL PROTECTED] writes: On Sat, 26 Nov 2005 04:59:59 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: On Fri, 25 Nov 2005 23:20:05 -0500, Mike Meyer wrote: If you've got a use case, I'd be interested in hearing it. frozenset perhaps? If it were needed once,

Re: Making immutable instances

2005-11-25 Thread Paul Rubin
Mike Meyer [EMAIL PROTECTED] writes: There isn't a standard serialize method in Python, so I don't know how you want to define it. Well, consider pickle, for example. I can think of perfectly reasonable definitions of serialize where obj.serialize() won't always return the same string on an

Re: Making immutable instances

2005-11-25 Thread [EMAIL PROTECTED]
Paul Rubin wrote: Fair enough. How's this: a = ImmutableObject() b = deepcopy(a) assert a == b # a and b start out equal do stuff # since a and b are immutable, they should still be equal # no matter what has happened above assert a == b If you've added

Re: Making immutable instances

2005-11-25 Thread Mike Meyer
Paul Rubin http://[EMAIL PROTECTED] writes: Mike Meyer [EMAIL PROTECTED] writes: There isn't a standard serialize method in Python, so I don't know how you want to define it. I can think of perfectly reasonable definitions of serialize where obj.serialize() won't always return the same string

Re: Making immutable instances

2005-11-25 Thread Steven D'Aprano
On Thu, 24 Nov 2005 12:55:07 +, Antoon Pardon wrote: Suppose I have the following code. from module import __take_care__ __private_detail__ = ... I now have two variable that are flaged the same way, but they are not. No, you have two names written using a poor naming convention.

Re: Making immutable instances

2005-11-25 Thread Steven D'Aprano
On Thu, 24 Nov 2005 11:44:16 -0500, Mike Meyer wrote: In Python, I can even fix it so *your* code uses my wrapped version: import Finney class Addable(Finnney.Immutable): pass Finney.Immutable = Addable Which means that from now on *your* code that tries to create Immutables will

Re: Making immutable instances

2005-11-25 Thread Mike Meyer
Steven D'Aprano [EMAIL PROTECTED] writes: On Thu, 24 Nov 2005 11:44:16 -0500, Mike Meyer wrote: In Python, I can even fix it so *your* code uses my wrapped version: import Finney class Addable(Finnney.Immutable): pass Finney.Immutable = Addable Python's consenting adults philosophy

Re: Making immutable instances

2005-11-25 Thread Steven D'Aprano
On Fri, 25 Nov 2005 20:50:41 -0500, Mike Meyer wrote: Steven D'Aprano [EMAIL PROTECTED] writes: On Thu, 24 Nov 2005 11:44:16 -0500, Mike Meyer wrote: In Python, I can even fix it so *your* code uses my wrapped version: import Finney class Addable(Finnney.Immutable): pass Finney.Immutable

Re: Making immutable instances

2005-11-25 Thread Mike Meyer
Steven D'Aprano [EMAIL PROTECTED] writes: Hmmm, the class designer didn't want me adding attributes to instances... maybe he had a good reason for that... When it was suggested that a facility for doing this be added to the language, I asked for a use case for it. Nobodies come up with a reason

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike Meyer wrote: If it's not a wart, why would it be a wart for user-defined types to have the same behaviour? It's a wart because user-defined classes *don't* have the same behavior. Then *my* solution for this would be to give user-defined classes a way to behave like builtins, eg.

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making immutable instances? IMHO, this is usually (but not always) a mistake. (If you're programming a missle

Re: Making immutable instances

2005-11-24 Thread Alex Martelli
[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... qualification, you're quite likely to get such disclaimers. If you don't want them, learn to ask about stopping your users from ACCIDENTALLY doing X, and no reasonable respondant will fail to notice the qualification. Interestingly, that

Re: Making immutable instances

2005-11-24 Thread [EMAIL PROTECTED]
Alex Martelli wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: ... qualification, you're quite likely to get such disclaimers. If you don't want them, learn to ask about stopping your users from ACCIDENTALLY doing X, and no reasonable respondant will fail to notice the

Re: Making immutable instances

2005-11-24 Thread [EMAIL PROTECTED]
Mike Meyer wrote: Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code. I certainly hope you're not relying on it

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code. I certainly hope you're not relying on it to catch bugs. You should

Re: Making immutable instances

2005-11-24 Thread Antoon Pardon
be observed in making immutable instances? IMHO, this is usually (but not always) a mistake. (If you're programming a missle guidance system, or it makes your program go faster it's not a mistake :)) So are PRIVATE, CONST (all types), SEALED, FINAL, etc -- even the best programmer doesn't foresee

Re: Making immutable instances

2005-11-24 Thread Scott David Daniels
Ben Finney wrote: Alex Martelli [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? You can make a good start by defining __setattr__, __delattr__ (and

Re: Making immutable instances

2005-11-24 Thread Ben Finney
Alex Martelli [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] wrote: Why is I want to make objects immutable seen as I don't trust my users? Are Python's existing immutable types also seen the same way? If not, why the distinction? A type implemented in C offers different

Re: Making immutable instances

2005-11-24 Thread Roel Schroeven
Antoon Pardon wrote: Op 2005-11-24, Mike schreef [EMAIL PROTECTED]: and many a time. I've been annoyed (in Java and MS christelijke vorm er van. frameworks) Antoon, I don't think Mike wrote it like that :) I don't even know how I spotted that, since I didn't really read that part of the text. I

Re: Making immutable instances

2005-11-24 Thread Antoon Pardon
Op 2005-11-24, Roel Schroeven schreef [EMAIL PROTECTED]: Antoon Pardon wrote: Op 2005-11-24, Mike schreef [EMAIL PROTECTED]: and many a time. I've been annoyed (in Java and MS christelijke vorm er van. frameworks) Antoon, I don't think Mike wrote it like that :) You are right, I don't know

Re: Making immutable instances

2005-11-24 Thread Mike
Giovanni Bajo [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Mike wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making immutable instances? IMHO

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
[EMAIL PROTECTED] [EMAIL PROTECTED] writes: Mike Meyer wrote: Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code.

Re: Making immutable instances

2005-11-24 Thread Mike
Antoon Pardon [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Op 2005-11-24, Mike schreef [EMAIL PROTECTED]: [...snip...] ...but I think Python's voluntary DoThis, _DoThisIfYouReallyHaveTo, and __You'dBetterKnowWhatYou'reDoing__ approach is a better way to go than the

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Ben Finney [EMAIL PROTECTED] writes: I'm looking for a consenting adults restriction: classes will have immutable instances only where it makes sense from the class protocol. I'm not going to lose sleep over users who go looking for trouble. I think you're defining immutable differently than I

Re: Making immutable instances

2005-11-24 Thread Mike
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Mike Meyer wrote: Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch

Re: Making immutable instances

2005-11-24 Thread Alex Martelli
Ben Finney [EMAIL PROTECTED] wrote: ... A type implemented in C offers different possibilities than one implemented in Python -- no deep conceptual reason, just practical ones. So, in the hypothetical situation that all Python types were implemented in pure Python, what would the

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code. I certainly hope you're not relying on it to catch bugs. You should do proper testing instead. Not only

Re: Making immutable instances

2005-11-24 Thread Björn Lindström
Giovanni Bajo [EMAIL PROTECTED] writes: My feeling is that you're trying to get too much out of my words. I'm not trying to handcuff anyone. You seem to concentrate on me trying to avoid people adding attributes to my precious objects. It's not that. If I write a class and want it to be

Re: Making immutable instances

2005-11-24 Thread Paul Rubin
[EMAIL PROTECTED] (Björn Lindström) writes: As I said before, I think you're confusing the (in Python pretty non-existent) concept of encapsulation with Python's immutable types, which are immutable because the implementation demands it. (A fact I hope will disappear at some point.) What

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Björn Lindström wrote: My feeling is that you're trying to get too much out of my words. I'm not trying to handcuff anyone. You seem to concentrate on me trying to avoid people adding attributes to my precious objects. It's not that. If I write a class and want it to be immutable, it is

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike wrote: There's a big difference. An immutable object has a totally different semantic, compared to a mutable object. If you document it to be immutable, and maybe even provide __eq__ /__hash__, adding attributes from it is surely an user bug. And surely a bug for which I'd expect an

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code. I certainly hope you're not relying on it to catch bugs. You

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Björn Lindström wrote: Why do you think we have a frozenset, for instance? By Mike's argument, we shouldn't have it. Not *my* arguments, certainly. Not unless you're seriously misinterpreting them. mike -- Mike Meyer [EMAIL PROTECTED]

Re: Making immutable instances

2005-11-24 Thread Alex Martelli
Giovanni Bajo [EMAIL PROTECTED] wrote: ... As I said before, I think you're confusing the (in Python pretty non-existent) concept of encapsulation with Python's immutable types, which are immutable because the implementation demands it. (A fact I hope will disappear at some point.)

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike Meyer wrote: And I have no problems with that. If you believe your class should throw an error if someone calls an instances pop() method when it's empty, do so. Likewise, if you want to make it so a client can't change your attributes, feel free to do so. However, when you prevent a

Re: Making immutable instances

2005-11-24 Thread Paul Rubin
Giovanni Bajo [EMAIL PROTECTED] writes: However, when you prevent a client from adding an attribute, you're not merely making your objects immutable, you're making them static. No I don't believe that. If an object is immutable, then obj.serialize() should return the same string every

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Paul Rubin wrote: Giovanni Bajo [EMAIL PROTECTED] writes: [pay attention to the quoting, I didn't write that :) ] Mike Meyer wrote: However, when you prevent a client from adding an attribute, you're not merely making your objects immutable, you're making them static. No I don't believe

Re: Making immutable instances

2005-11-24 Thread Giovanni Bajo
Mike Meyer wrote: Björn Lindström wrote: Why do you think we have a frozenset, for instance? By Mike's argument, we shouldn't have it. Not *my* arguments, certainly. Not unless you're seriously misinterpreting them. Sorry then, I probably am. There must be a misunderstanding somewhere.

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: And I have no problems with that. If you believe your class should throw an error if someone calls an instances pop() method when it's empty, do so. Likewise, if you want to make it so a client can't change your attributes, feel free

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Paul Rubin http://[EMAIL PROTECTED] writes: Giovanni Bajo [EMAIL PROTECTED] writes: However, when you prevent a client from adding an attribute, you're not merely making your objects immutable, you're making them static. No I don't believe that. If an object is immutable, then

Re: Making immutable instances

2005-11-24 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Mike Meyer wrote: Björn Lindström wrote: Why do you think we have a frozenset, for instance? By Mike's argument, we shouldn't have it. Not *my* arguments, certainly. Not unless you're seriously misinterpreting them. Sorry then, I probably am. There

Re: Making immutable instances

2005-11-23 Thread Giovanni Bajo
Ben Finney wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making immutable instances? In short, you can't. I usually try harder to derive from tuple to achieve

Re: Making immutable instances

2005-11-23 Thread Mike Meyer
Giovanni Bajo [EMAIL PROTECTED] writes: Ben Finney wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making immutable instances? In short, you can't. I usually try

Re: Making immutable instances

2005-11-23 Thread Ben Finney
Mike Meyer [EMAIL PROTECTED] wrote: Giovanni Bajo [EMAIL PROTECTED] writes: In short, you can't. I usually try harder to derive from tuple to achieve this (defining a few read-only properties to access item through attributes). Using __slots__ is then required to avoid people adding

Re: Making immutable instances

2005-11-23 Thread Björn Lindström
Mike Meyer [EMAIL PROTECTED] writes: I'm curious as to why you care if people add attributes to your immutable class. Personally, I consider that instances of types don't let me add attributes to be a wart. I agree. To me it seems like the OP kind of wants to implement encapsulation from the

Re: Making immutable instances

2005-11-23 Thread Mike Meyer
Ben Finney [EMAIL PROTECTED] writes: Are there other, more dependable, ways of making immutable objects? Your answer can be found at URL: http://www.cs.bgu.ac.il/~omri/Humor/write_in_c.html I'm curious as to why you care if people add attributes to your immutable class. Personally, I

Re: Making immutable instances

2005-11-23 Thread Alex Martelli
, such as __iadd__ and friends (or, if you're inheriting from a class that does define them, override them to raise exceptions). What caveats should be observed in making immutable instances? Remember that your redefined __setattr__ IS in place even when you're initializing your istance, so

Re: Making immutable instances

2005-11-23 Thread Ben Finney
Alex Martelli [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? You can make a good start by defining __setattr__, __delattr__ (and __setitem__

Re: Making immutable instances

2005-11-23 Thread Ben Finney
Alex Martelli [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] wrote: How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? [...] Of course, these restrictions can be easily worked around by a

Re: Making immutable instances

2005-11-23 Thread Alex Martelli
Ben Finney [EMAIL PROTECTED] wrote: ... Remember that your redefined __setattr__ IS in place even when you're initializing your istance, so remember to delegate attribute setting to the superclass (the other special methods mentioned above are less likely to byte you). So, for a

Re: Making immutable instances

2005-11-23 Thread Alex Martelli
Ben Finney [EMAIL PROTECTED] wrote: ... Of course, these restrictions can be easily worked around by a sufficiently determined attacker... but if you have to think of the user of your code as an attacker, you've got worse problems than this trifling one. I've probably stumbled across

Re: Making immutable instances

2005-11-23 Thread [EMAIL PROTECTED]
Alex Martelli wrote: A substantial fraction of the time, people asking how do I stop the users of my code from doing X proceed by screaming but they could still do X if they hopped on their left foot in a moonless midnight while sprinkling bat's blood! as a response to any suggestion. So,

Re: Making immutable instances

2005-11-23 Thread Mike
Ben Finney [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Howdy all, How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making immutable instances? IMHO

Re: Making immutable instances

2005-11-23 Thread Giovanni Bajo
Mike Meyer wrote: Note that this property of __slots__ is an implementation detail. You can't rely on it working in the future. I don't rely on it. I just want to catch bugs in my code. I'm curious as to why you care if people add attributes to your immutable class. Personally, I consider