I am sorry all I am not here to just blame Python. This is just an introspection of whether what I believe is right. Being a devotee of Python from past 2 years I have been writing only small apps and singing praises about Python where ever I go. I now got a chance to read Django's code for some reason. I have now strongly started feeling if Python really follows its "Readability Counts" philosophy. For example,
class A: a = 10 b = "Madhu"
def somemethod(self, arg1): self.c = 20.22 d = "some local variable" # do something .... ... def somemethod2 (self, arg2): self.c = "Changed the variable" # do something 2 ...
In such situations, where the Instance variables come into existence only when they are used it is very difficult to track the flow of code. Its obviously not possible to remember what instance variable was defined where, when reading some substantial amount of code and where it was manipulated for that matter. It becomes so very frustrating even when reading a Class's code with just 6-8 methods and not more than 100-150 lines of code.
I am interested in knowing if I am reading this kind of code in the wrong way mostly because of C++/Java hangover since most other languages follow the same approach as them? If there is a Pythonic way reading this code for better readability? What made Python developers to adopt this strange strategy keeping "Readibility Counts" in mind?
On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <madhusuda...@gmail.com> wrote: > I am sorry all I am not here to just blame Python. This is just an > introspection of whether > what I believe is right. Being a devotee of Python from past 2 years I > have been writing only > small apps and singing praises about Python where ever I go. I now got > a chance to read > Django's code for some reason. I have now strongly started feeling if > Python really follows its > "Readability Counts" philosophy. For example,
> class A: > a = 10 > b = "Madhu"
Those are class variables, not instance variables. There is a distinct difference. Instance variables, in contrast, are "declared" and created in the body of the __init__ method.
> def somemethod(self, arg1): > self.c = 20.22 > d = "some local variable" > # do something > .... > ... > def somemethod2 (self, arg2): > self.c = "Changed the variable" > # do something 2 > ...
> In such situations, where the Instance variables come into existence > only when they are used > it is very difficult to track the flow of code. Its obviously not > possible to remember what > instance variable was defined where, when reading some substantial > amount of code and where > it was manipulated for that matter. It becomes so very frustrating > even when reading a Class's > code with just 6-8 methods and not more than 100-150 lines of code.
That's bad coding style on the part of the code writer. Conditionally-existing instance variables are *evil*.
> Django's code for some reason. I have now strongly started feeling if > Python really follows its > "Readability Counts" philosophy. For example,
> class A: > a = 10 > b = "Madhu"
> def somemethod(self, arg1): > self.c = 20.22 > d = "some local variable" > # do something > .... > ... > def somemethod2 (self, arg2): > self.c = "Changed the variable" > # do something 2 > ...
In this case is the "c" attribute not "declared" in the __init__() method of A?
> I am interested in knowing if I am reading this kind of code in the > wrong way mostly because > of C++/Java hangover since most other languages follow the same > approach as them? If there > is a Pythonic way reading this code for better readability? What made > Python developers to > adopt this strange strategy keeping "Readibility Counts" in mind?
Not declaring instance variables is just poor form. IMHO Python code should mostly be written like C++/Java. When you use "tricks" like the above (dynamically adding attributes to a class) or getattr calls, catching AttributeErrors, manipulating __dict__, decorators or metaclasses you should really think twice whether you actually _need_ to use those tricks.
On Jan 11, 3:22 pm, "Madhusudan.C.S" <madhusuda...@gmail.com> wrote:
> I am sorry all I am not here to just blame Python. This is just an > introspection of whether > what I believe is right. Being a devotee of Python from past 2 years I > have been writing only > small apps and singing praises about Python where ever I go. I now got > a chance to read > Django's code for some reason. I have now strongly started feeling if > Python really follows its > "Readability Counts" philosophy.
Ok, let's clear up a couple misconceptions right now.
First: "Reabability counts" is a design principle of the language, not a mandate that every Python programmer write readable code. If Django project wants to write less readable code, they can. "Readability counts" means that Python is designed to make it easy for the Django project to write readable code if they choose.
Second: "Readability counts" is not the only factor that matters. There are 19 Zen and sometimes they conflict with each other. Python tries to balance all these concerns; it doesn't greedily maximize any one of them. Some things might be a little less readable than they could be, but oftentimes that's because other design considerations were judged more important in that case.
Having cleared that up, let's consider your specific points.
> def somemethod(self, arg1): > self.c = 20.22 > d = "some local variable" > # do something > .... > ... > def somemethod2 (self, arg2): > self.c = "Changed the variable" > # do something 2 > ...
> In such situations, where the Instance variables come into existence > only when they are used > it is very difficult to track the flow of code. Its obviously not > possible to remember what > instance variable was defined where, when reading some substantial > amount of code
Impossible? You are seriously overstating things.
> and where > it was manipulated for that matter.
This criticism is completely unfair. Instance variables have to be manipulated somewhere, and unless your object is immutable, that is going to happen outside of __init__. That's true in Java, C++, and pretty much any other language.
> It becomes so very frustrating > even when reading a Class's > code with just 6-8 methods and not more than 100-150 lines of code.
> I am interested in knowing if I am reading this kind of code in the > wrong way mostly because > of C++/Java hangover since most other languages follow the same > approach as them?
(Well, it is a lot safer in Python. In C++, if you try to use an uninitialized variable, you'd get undefined behavior. Better to initialize it to null and at least get a guaranteed segfault. In Python if you try to use an uninitialized variable you'd get an AttributeError.)
> If there > is a Pythonic way reading this code for better readability? What made > Python developers to > adopt this strange strategy keeping "Readibility Counts" in mind?
I'm not going to argue that this doesn't hurt readability, because it does (though not nearly as much as you claim). But there are other considerations, and in this case the flexibility of defining attributes outside __init__ is worth the potential decrease in readability.
Here's a couple examples of where it's useful:
1. Sometimes classes are initialized without calling __init__, strange but true. Look at the pickle module, for instance. It creates the object without calling __init__ then sets all the instance variables itself.
2. Some classes have factory classmethods that create the object by a different means than calling __init__. (In fact, some classes have an internal method that initializes variables, which __init__ and the factories both call.)
3. Some objects, such as proxies, have uncertain sets of attributes. Requiring such objects to predict all the variables they need inside __init__ would limit their usability. Programmers would probably resort to hack-like workarounds like Decorator Design Pattern.
4. It allows a simplification of the object system. Right now, all attribute access is handled identically: at any point in time any attribute may be set. If you wanted to limit attribute creation to __init__, then it would mean objects have to have two phases (one, during __init__, where you can create attributes; the other, where you can only modify them). This would add significant complexity, and "Simple is better than complex.
I'll also point out that even in C++/Java/etc. you have occasions where an instance variable doesn't do anything until a something triggers it. You can look to the constructor to see what it's initialized to, but it isn't really initialized to anything useful until some method call sets it to something useful. (Python makes it explicit that the variable isn't in use until it is initialized, and "Explicit is better than implicit".)
In the end, the answer to you question is simply, "Readibilty counts, but other stuff matters too."
Carl Banks <pavlovevide...@gmail.com> writes: > and where it was manipulated for that matter.
> This criticism is completely unfair. Instance variables have to be > manipulated somewhere, and unless your object is immutable, that is > going to happen outside of __init__. That's true in Java, C++, and > pretty much any other language.
The criticism is very valid. Some languages do support immutable variables (e.g. "final" declarations in Java, "const" in C++, or universal immutability in pure functional languages) and they do so precisely for the purpose of taming the chaos of uncontrolled mutation. It would be great if Python also supported immutability.
> I'm not going to argue that this doesn't hurt readability, because it > does (though not nearly as much as you claim). But there are other > considerations, and in this case the flexibility of defining > attributes outside __init__ is worth the potential decrease in > readability.
There are cases where this is useful but they're not terribly common. I think it would be an improvement if creating new object attributes was by default not allowed outside the __init__ method. In the cases where you really do want to create new attributes elsewhere, you'd have to explicitly enable this at instance creation time, for example by inheriting from a special superclass:
class Foo (DynamicAttributes, object): pass
> 4. It allows a simplification of the object system. Right now, all > attribute access is handled identically: at any point in time any > attribute may be set. If you wanted to limit attribute creation to > __init__, then it would mean objects have to have two phases (one, > during __init__, where you can create attributes; the other, where you > can only modify them). This would add significant complexity, and > "Simple is better than complex.
> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <madhusuda...@gmail.com> wrote: > > def somemethod(self, arg1): > > self.c = 20.22 > > d = "some local variable" > > # do something > > .... > > ... > > def somemethod2 (self, arg2): > > self.c = "Changed the variable" > > # do something 2 > > ...
> > In such situations, where the Instance variables come into existence > > only when they are used > > it is very difficult to track the flow of code. Its obviously not > > possible to remember what > > instance variable was defined where, when reading some substantial > > amount of code and where > > it was manipulated for that matter. It becomes so very frustrating > > even when reading a Class's > > code with just 6-8 methods and not more than 100-150 lines of code.
> That's bad coding style on the part of the code writer. > Conditionally-existing instance variables are *evil*.
Do you mean conditionally-useful instance variables evil, or that conditionally-useful variables are ok but it's evil for them to conditionally-exist?
The former I don't agree with at all.
If it's the latter, I believe there is something to be said for variables that exist when they are needed and don't when they're not. However, I acknowledge that listing all the variables you intend to use in __init__ is highly comforting, even if it does belie their current uselessness.
On Jan 11, 5:02 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Carl Banks <pavlovevide...@gmail.com> writes: > > and where it was manipulated for that matter.
> > This criticism is completely unfair. Instance variables have to be > > manipulated somewhere, and unless your object is immutable, that is > > going to happen outside of __init__. That's true in Java, C++, and > > pretty much any other language.
> The criticism is very valid. Some languages do support immutable > variables (e.g. "final" declarations in Java, "const" in C++, or > universal immutability in pure functional languages) and they do so > precisely for the purpose of taming the chaos of uncontrolled > mutation. It would be great if Python also supported immutability.
I don't think what you said (which is fine) makes his criticism valid, unless you also suggest that all objects should be immutable.
If any objects are mutable, you have to be prepared for objects to mutated outside the initializer.
I guess it could be a valid criticism of Django's progamming style ("They mutate stuff haphazardly everywhere!!~") but that's not the Python langauge's problem.
> > 4. It allows a simplification of the object system. Right now, all > > attribute access is handled identically: at any point in time any > > attribute may be set. If you wanted to limit attribute creation to > > __init__, then it would mean objects have to have two phases (one, > > during __init__, where you can create attributes; the other, where you > > can only modify them). This would add significant complexity, and > > "Simple is better than complex.
> On the other hand, correct is better than buggy.
What bugginess do you speak of? Adding a variable outside __init__ is questionable style, not a bug. I don't think it's a significant source of bugs, either. And I definitely don't think the language should add a layer of complexity (and I think you're underestimating the complexity of making the whole object system two-phase) just to prevent a minor style issue.
pychecker is the appropriate tool to diagnose this issue.
Carl Banks <pavlovevide...@gmail.com> writes: > > The criticism is very valid. Some languages do support immutable > > variables (e.g. "final" declarations in Java, "const" in C++, or > > universal immutability in pure functional languages) and they do so > > precisely for the purpose of taming the chaos of uncontrolled > > mutation. It would be great if Python also supported immutability.
> I don't think what you said (which is fine) makes his criticism valid, > unless you also suggest that all objects should be immutable.
It would be enough to have a way to make specific objects and instance attributes immutable.
> If any objects are mutable, you have to be prepared for objects to > mutated outside the initializer.
Sure, but why have mutable objects all over the place? And, why always have attributes visible at all, outside the class definition? The approach in C++ and Java is to have public and private instance variables, where the private ones are visible only in the class methods.
On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks <pavlovevide...@gmail.com> wrote: > On Jan 11, 3:31 pm, Chris Rebert <c...@rebertia.com> wrote: >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <madhusuda...@gmail.com> wrote: >> > def somemethod(self, arg1): >> > self.c = 20.22 >> > d = "some local variable" >> > # do something >> > .... >> > ... >> > def somemethod2 (self, arg2): >> > self.c = "Changed the variable" >> > # do something 2 >> > ...
>> > In such situations, where the Instance variables come into existence >> > only when they are used >> > it is very difficult to track the flow of code. Its obviously not >> > possible to remember what >> > instance variable was defined where, when reading some substantial >> > amount of code and where >> > it was manipulated for that matter. It becomes so very frustrating >> > even when reading a Class's >> > code with just 6-8 methods and not more than 100-150 lines of code.
>> That's bad coding style on the part of the code writer. >> Conditionally-existing instance variables are *evil*.
> Do you mean conditionally-useful instance variables evil, or that > conditionally-useful variables are ok but it's evil for them to > conditionally-exist?
> The former I don't agree with at all.
> If it's the latter, I believe there is something to be said for > variables that exist when they are needed and don't when they're not. > However, I acknowledge that listing all the variables you intend to > use in __init__ is highly comforting, even if it does belie their > current uselessness.
The latter. I never even used the word "useful", so I have no idea where you got that from. To reiterate, variables which might only exist under certain conditions are evil, IMHO. This is not to say they are not useful in certain specific cases, just that in general there are better ways to design/structure programs to avoid them.
<"http://phr.cx"@nospam.invalid> wrote: > Carl Banks <pavlovevide...@gmail.com> writes: <snip> >> If any objects are mutable, you have to be prepared for objects to >> mutated outside the initializer.
> Sure, but why have mutable objects all over the place? And, why > always have attributes visible at all, outside the class definition? > The approach in C++ and Java is to have public and private instance > variables, where the private ones are visible only in the class methods.
Regarding the second question, Python adheres to the principle that "We're all consenting adults here" and so does not provide complete encapsulation like more B&D languages. This is handy sometimes as it allows one to break through the encapsulation when necessary and fiddle with the internals. This is not to say that breaking encapsulation willy-nilly is advised, but it does allow for some neat hackery every now and again.
[Dynamically adding and removing instance attributes...]
> Here's a couple examples of where it's useful:
> 1. Sometimes classes are initialized without calling __init__, [...] > 2. Some classes have factory classmethods [...] > 3. Some objects, such as proxies, have uncertain sets of attributes. [...] > 4. It allows a simplification of the object system. [...]
All good points. I'd like to add a fifth: it can provide a handy hook for one module to hang data off of another module's objects. This sort of thing isn't very nice, but it's sometimes the best way.
(Other approaches include using wrappers, which might be very invasive if opaque, or don't actually solve the name-collision problem if transparent; or maintaining a dictionary, which involves messing about with weak pointers if you want to keep it from filling with cruft.)
> In the end, the answer to you question is simply, "Readibilty counts, > but other stuff matters too."
In article <34c95e04-5b3f-44bc-a5bf-498518507...@p36g2000prp.googlegroups.com>,
"Madhusudan.C.S" <madhusuda...@gmail.com> wrote: > In such situations, where the Instance variables come into existence > only when they are used it is very difficult to track the flow of code.
As the saying goes, "It's possible to write Fortran in any language".
My personal habit is to "declare" all instance variables in the __init__() method of every class. If there's no better value, I set them to None. This isn't strictly required, but I think it makes it easier for somebody reading the code to understand the class.
I'm not a big fan of dogmatic rules, other than the rule that says you should make your code as easy for somebody else to understand as possible.
> On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks <pavlovevide...@gmail.com> wrote: > > On Jan 11, 3:31 pm, Chris Rebert <c...@rebertia.com> wrote: > >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <madhusuda...@gmail.com> wrote: > >> > def somemethod(self, arg1): > >> > self.c = 20.22 > >> > d = "some local variable" > >> > # do something > >> > .... > >> > ... > >> > def somemethod2 (self, arg2): > >> > self.c = "Changed the variable" > >> > # do something 2 > >> > ...
> >> > In such situations, where the Instance variables come into existence > >> > only when they are used > >> > it is very difficult to track the flow of code. Its obviously not > >> > possible to remember what > >> > instance variable was defined where, when reading some substantial > >> > amount of code and where > >> > it was manipulated for that matter. It becomes so very frustrating > >> > even when reading a Class's > >> > code with just 6-8 methods and not more than 100-150 lines of code.
> >> That's bad coding style on the part of the code writer. > >> Conditionally-existing instance variables are *evil*.
> > Do you mean conditionally-useful instance variables evil, or that > > conditionally-useful variables are ok but it's evil for them to > > conditionally-exist?
> > The former I don't agree with at all.
> > If it's the latter, I believe there is something to be said for > > variables that exist when they are needed and don't when they're not. > > However, I acknowledge that listing all the variables you intend to > > use in __init__ is highly comforting, even if it does belie their > > current uselessness.
> The latter. I never even used the word "useful", so I have no idea > where you got that from.
I was just asking for clarification of your rationale, of which I imagined two possibilities ("conditional-usefulness is bad", or "declaring attributes outside of __init__" is bad). However...
> To reiterate, variables which might only exist under certain > conditions are evil, IMHO. > This is not to say they are not useful in certain specific cases, just > that in general there are better ways to design/structure programs to > avoid them.
...the way you phrase this suggests to me that conditional-usefulness *is* what you are really concerned with. Let me give you an example:
class A: def __init__(self): pass def something(self): self._conditionally_existent_variable = 1
ISTM that I don't need any restructuring at all to avoid conditional existence; all I'd have to do is add
self._conditionally_existent_variable = None
to __init__. If you think I need to restructure this code, than you evidently care about something more than just conditional existence. If so, what is it that's so evil about conditionally-existent variables? (I'll leave the question open-ended this time.)
> In article > <34c95e04-5b3f-44bc-a5bf-498518507...@p36g2000prp.googlegroups.com>,
> "Madhusudan.C.S" <madhusuda...@gmail.com> wrote: > > In such situations, where the Instance variables come into existence > > only when they are used it is very difficult to track the flow of code.
> As the saying goes, "It's possible to write Fortran in any language".
> My personal habit is to "declare" all instance variables in the __init__() > method of every class. If there's no better value, I set them to None. > This isn't strictly required, but I think it makes it easier for somebody > reading the code to understand the class.
> I'm not a big fan of dogmatic rules, other than the rule that says you > should make your code as easy for somebody else to understand as possible.
Roy i totally agree and as i read down this thread i was thinking i might get to spit that out first but you beat me -- Darn!
PS: your explanation is also much more eloquent than mine would have been :)
Carl Banks <pavlovevide...@gmail.com> writes: > If so, what is it that's so evil about conditionally-existent > variables? (I'll leave the question open-ended this time.)
I have found they make the code more confusing and bug prone. It's better to define and document all the instance variables in one place, in most cases.
On Jan 11, 5:41 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Carl Banks <pavlovevide...@gmail.com> writes: > > > The criticism is very valid. Some languages do support immutable > > > variables (e.g. "final" declarations in Java, "const" in C++, or > > > universal immutability in pure functional languages) and they do so > > > precisely for the purpose of taming the chaos of uncontrolled > > > mutation. It would be great if Python also supported immutability.
> > I don't think what you said (which is fine) makes his criticism valid, > > unless you also suggest that all objects should be immutable.
> It would be enough to have a way to make specific objects and instance > attributes immutable.
Enough for what, to make the guy's criticism valid? No it wouldn't. Or are you just ignoring the OP altogether and complaining about what bothers you?
For my part I am concerned with answering the OP's issues here, not yours.
> > If any objects are mutable, you have to be prepared for objects to > > mutated outside the initializer.
> Sure, but why have mutable objects all over the place? And, why > always have attributes visible at all, outside the class definition? > The approach in C++ and Java is to have public and private instance > variables, where the private ones are visible only in the class methods.
The OP wasn't complaining about the fact that objects aren't immutable, as far as I can tell, nor about having public and private variables, so I can't agree Python's lack of these has anything to do with the OP's concerns.
On Jan 11, 6:42 pm, Paul Rubin <http://phr...@NOSPAM.invalid> wrote:
> Carl Banks <pavlovevide...@gmail.com> writes: > > If so, what is it that's so evil about conditionally-existent > > variables? (I'll leave the question open-ended this time.)
> I have found they make the code more confusing and bug prone. > It's better to define and document all the instance variables > in one place, in most cases.
That means all I have to do is add a stopgap value in __init__. I'm asking Chris why that is evidently not enough, and that I'd have to structure/design my code to avoid it.
On Sun, Jan 11, 2009 at 4:33 PM, Carl Banks <pavlovevide...@gmail.com> wrote: > On Jan 11, 5:49 pm, Chris Rebert <c...@rebertia.com> wrote: >> On Sun, Jan 11, 2009 at 3:15 PM, Carl Banks <pavlovevide...@gmail.com> wrote: >> > On Jan 11, 3:31 pm, Chris Rebert <c...@rebertia.com> wrote: >> >> On Sun, Jan 11, 2009 at 1:22 PM, Madhusudan.C.S <madhusuda...@gmail.com> wrote: >> >> > def somemethod(self, arg1): >> >> > self.c = 20.22 >> >> > d = "some local variable" >> >> > # do something >> >> > .... >> >> > ... >> >> > def somemethod2 (self, arg2): >> >> > self.c = "Changed the variable" >> >> > # do something 2 >> >> > ...
>> >> > In such situations, where the Instance variables come into existence >> >> > only when they are used >> >> > it is very difficult to track the flow of code. Its obviously not >> >> > possible to remember what >> >> > instance variable was defined where, when reading some substantial >> >> > amount of code and where >> >> > it was manipulated for that matter. It becomes so very frustrating >> >> > even when reading a Class's >> >> > code with just 6-8 methods and not more than 100-150 lines of code.
>> >> That's bad coding style on the part of the code writer. >> >> Conditionally-existing instance variables are *evil*.
>> > Do you mean conditionally-useful instance variables evil, or that >> > conditionally-useful variables are ok but it's evil for them to >> > conditionally-exist?
>> > The former I don't agree with at all.
>> > If it's the latter, I believe there is something to be said for >> > variables that exist when they are needed and don't when they're not. >> > However, I acknowledge that listing all the variables you intend to >> > use in __init__ is highly comforting, even if it does belie their >> > current uselessness.
>> The latter. I never even used the word "useful", so I have no idea >> where you got that from.
> I was just asking for clarification of your rationale, of which I > imagined two possibilities ("conditional-usefulness is bad", or > "declaring attributes outside of __init__" is bad). However...
>> To reiterate, variables which might only exist under certain >> conditions are evil, IMHO. >> This is not to say they are not useful in certain specific cases, just >> that in general there are better ways to design/structure programs to >> avoid them.
> ...the way you phrase this suggests to me that conditional-usefulness > *is* what you are really concerned with. Let me give you an example:
> ISTM that I don't need any restructuring at all to avoid conditional > existence; all I'd have to do is add
> self._conditionally_existent_variable = None
> to __init__. If you think I need to restructure this code, than you > evidently care about something more than just conditional existence.
No, this is exactly the sort of restructuring I was referring to; and nothing more. Making that one-line change would be sufficient for me. Perhaps "restructuring" was a poor choice of words...
> Carl Banks <pavlovevide...@gmail.com> writes: > > and where it was manipulated for that matter.
> > This criticism is completely unfair. Instance variables have to be > > manipulated somewhere, and unless your object is immutable, that is > > going to happen outside of __init__. That's true in Java, C++, and > > pretty much any other language.
> The criticism is very valid. Some languages do support immutable > variables (e.g. "final" declarations in Java, "const" in C++, or > universal immutability in pure functional languages) and they do so > precisely for the purpose of taming the chaos of uncontrolled > mutation. It would be great if Python also supported immutability.
> > I'm not going to argue that this doesn't hurt readability, because it > > does (though not nearly as much as you claim). But there are other > > considerations, and in this case the flexibility of defining > > attributes outside __init__ is worth the potential decrease in > > readability.
> There are cases where this is useful but they're not terribly common. > I think it would be an improvement if creating new object attributes > was by default not allowed outside the __init__ method. In the cases > where you really do want to create new attributes elsewhere, you'd > have to explicitly enable this at instance creation time, for example > by inheriting from a special superclass:
> class Foo (DynamicAttributes, object): pass
You cannot do that, but you can establish a fixed set of attributes by defining the __slot__ class variable.
Traceback (most recent call last): File "<interactive input>", line 1, in <module> File "<interactive input>", line 3, in __init__ AttributeError: 'A' object has no attribute 'not_allowed'
On Mon, 12 Jan 2009 07:42:47 -0800, bieffe62 wrote: > On 12 Gen, 14:45, Paul Rubin <http://phr...@NOSPAM.invalid> wrote: >> bieff...@gmail.com writes: >> > > class Foo (DynamicAttributes, object): pass
>> > You cannot do that, but you can establish a fixed set of attributes >> > by defining the __slot__ class variable.
>> That is not what __slot__ is for.
> Really? It seems to work:
It works but it is not what `__slot__` was invented for. Some call it a misuse of that feature if you use it to prevent adding attributes dynamically. And it has some drawbacks when you inherit from such classes.
> Carl Banks <pavlovevide...@gmail.com> writes: >>> The criticism is very valid. Some languages do support immutable >>> variables (e.g. "final" declarations in Java, "const" in C++, or >>> universal immutability in pure functional languages) and they do so >>> precisely for the purpose of taming the chaos of uncontrolled >>> mutation. It would be great if Python also supported immutability. >> I don't think what you said (which is fine) makes his criticism valid, >> unless you also suggest that all objects should be immutable.
> It would be enough to have a way to make specific objects and instance > attributes immutable.
>> If any objects are mutable, you have to be prepared for objects to >> mutated outside the initializer.
> Sure, but why have mutable objects all over the place? And, why > always have attributes visible at all, outside the class definition? > The approach in C++ and Java is to have public and private instance > variables, where the private ones are visible only in the class methods.
Why on earth are you using Python if you don't like the way it work ???
