Re: Making immutable instances

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" >>

Re: Making immutable instances

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 immut

Re: Making immutable instances

[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 >> tha

Re: Making immutable instances

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 bo

Re: Making immutable instances

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 immuta

Re: Making immutable instances

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 l

Re: Making immutable instances

[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 B&D language features. It's generally considered that it's not >> a good enough reason for adding t

Re: Making immutable instances

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

Re: Making immutable instances

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 B&D language features. It's generally considered that it's not > a good enough reason for adding those, so it doesn't really cons

Re: Making immutable instances

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,

Re: Making immutable instances

Paul Rubin 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

Re: Making immutable instances

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, d

RE: Making immutable instances

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 -- http://mail.python.org/mailman/l

Re: Making immutable instances

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 wa

Re: Making immutable instances

[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 - >>

RE: Making immutable instances

"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

Re: Making immutable instances

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 "

Re: Making immutable instances

[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

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-depende

Re: Making immutable instances

[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

RE: Making immutable instances

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

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 ti

Re: Making immutable instances

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 f

Re: Making immutable instances

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 f

Re: Making immutable instances

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 n

Re: Making immutable instances

[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 work

Re: Making immutable instances

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

[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. Fo

Re: Making immutable instances

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 calli

Re: Making immutable instances

[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 ob

Re: Making immutable instances

Paul Rubin 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 >

Re: Making immutable instances

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

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,

Re: Making immutable instances

Paul Rubin 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

Re: Making immutable instances

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 s

Re: Making immutable instances

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 the

Re: Making immutable instances

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 w

Re: Making immutable instances

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. > > T

Re: Making immutable instances

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

Re: Making immutable instances

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 > l

Re: Making immutable instances

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 r

Re: Making immutable instances

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): pas

Re: Making immutable instances

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

Re: Making immutable instances

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 wi

Re: Making immutable instances

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 convent

Re: Making immutable instances

Paul Rubin 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

Re: Making immutable instances

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 yo

Re: Making immutable instances

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 >

Re: Making immutable instances

"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 pro

Re: Making immutable instances

Paul Rubin 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,

Re: Making immutable instances

"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 >> attribut

Re: Making immutable instances

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 somew

Re: Making immutable instances

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. >

Re: Making immutable instances

"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 e

Re: Making immutable instances

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 pr

Re: Making immutable instances

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 poi

Re: Making immutable instances

"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. http://www.mired.org

Re: Making immutable instances

"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 t

Re: Making immutable instances

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'

Re: Making immutable instances

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 i

Re: Making immutable instances

[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 i

Re: Making immutable instances

"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 b

Re: Making immutable instances

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 ins

Re: Making immutable instances

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 woul

Re: Making immutable instances

<[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

Re: Making immutable instances

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

Re: Making immutable instances

"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

"[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

Re: Making immutable instances

"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

Re: Making immutable instances

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

Re: Making immutable instances

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 t

Re: Making immutable instances

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 dif

Re: Making immutable instances

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_

Re: Making immutable instances

Op 2005-11-24, Mike schreef <[EMAIL PROTECTED]>: > > "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

Re: Making immutable instances

"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.

Re: Making immutable instances

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

Re: Making immutable instances

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 > >

Re: Making immutable instances

[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. > Interestin

Re: Making immutable instances

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 > programm

Re: Making immutable instances

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

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 con

Re: Making immutable instances

"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? IM

Re: Making immutable instances

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.

Re: Making immutable instances

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 stum

Re: Making immutable instances

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). > > S

Re: Making immutable instances

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

Re: Making immutable instances

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

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__ and __delitem__ if your class is a conta

Re: Making immutable instances

Ben Finney <[EMAIL PROTECTED]> writes: > Are there other, more dependable, ways of making immutable objects? Your answer can be found at 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 con

Re: Making immutable instances

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 fro

Re: Making immutable instances

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 > > peopl

Re: Making immutable instances

"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.

Re: Making immutable instances

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 achiev