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
[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
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
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
--
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
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
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
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
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
[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
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
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
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
[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
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
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
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
[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.
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
[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,
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
[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
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.
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,
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,
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.
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
[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
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.
[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.
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
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
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
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
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
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,
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
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
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
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,
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
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
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
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.
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
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
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
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
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.
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
[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
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
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
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
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
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
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
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
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
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
[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.
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
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
[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
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
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
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
[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
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
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
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
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]
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.)
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
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
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
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.
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
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
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
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
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
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
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
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
, 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
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__
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
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
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
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,
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
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
93 matches
Mail list logo
