> > Apparently many programmers felt this lack, including Guido, and added > > the missing capability. > > Can you please support your statement! >
The fact that it was added isn't evidence programmers wanted it added? > Guido added properties to the language. No doubt. He says they are about > "managed attributes". His example in the original presentation of the use > of properties was quite narrow. In fact it was only in referring back to > it that I feel I began to get my head on straight about what properties > were really intended to be about (IMO). > > I believe I am interpreting his purpose much more carefully then are you. > > You feel otherwise. The whole idea of attributes managed through setters and getters (mutators) is a known design pattern. SmallTalk wouldn't even allow direct assignment to attributes, right? *All* access to variables is "managed." Setters and getters are built into C# as well, at the syntax level. Not because of Python though. We're talking about a feature of the OO model that's been around for awhile. Python acquired this feature later in its development, but not out of the blue. Like many features in Python, you can point to their precedents in other languages. List comprehensions from Haskell, generators from Icon... (correct me if I'm wrong). Many programmers wouldn't need to closely study Guido's examples to show what properties are good for; it'd was already a tool in their tool chest, in other languages (or in Python using __setattr__ and __getattr__ -- less convenient). You come to OO through Python and all of a sudden it acquires one of these new (to you) features. To you, it seems like something alien is creeping in, perhaps against some deep-seated philosophy that you've come to respect. You worry something valuable is being undermined. These developments seem sinister, all about "information hiding" or whatever. But to someone else, a long-time OO coder (who maybe started in SmallTalk) the reaction is more like "about time, what took you so long?" > We are in Lit class arguing interpretation, the author's intent. Some > authors successfully use ambiguity to their advantage. Perhaps there is a > good deal here. But in this milieu I can't believe a straight forward > reading of the author's stated intent - which is where I feel I am - is > without merit. > > Maybe the cigar is just a cigar. > Kinda cryptic. I think people are being quite up front about what properties are good for, why other programming languages besides Python manage access to attributes (e.g. to protect private variables from direct exposure through the API). Python could get along nicely without 'em at first, sure, but adding a property method was a small price to pay for a valuable feature programmers have come to expect within the OO paradigm. What's so hard to understand here? > I am dark and paranoid when I confront what I (rightly or wrongly) > interpret as some form of group think. There are reasons for it. > Apologies. > > Art What's wrong with "group think"? I know we're supposed to reflexively dislike the sound of that, but when a community reaches a consensus, based on professional history and prior experience, must it always be wrong? I feel the explanations put forward for why the property feature was added have made plenty of sense. You seem to reject them on the basis of: well if *I* Arthur didn't need them, how come anyone else should? I felt the same way about Guido's change to the division operator. In the new design, a/b will always be a float, a//b always an integer -- much better, and not a politically motivated cave-in to newbies learning VPython (the dark motive you always persisted in reading in). Perhaps my version of Python is evolving at a faster rate, and in different directions, than you necessarily need in your version, for what you're trying to do. What's the harm in that, as long as your code still runs? Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
