Re: conceptual problem (was: A beginning beginner's question about input, output and . . .
On 14/01/21 11:49 am, Cameron Simpson wrote: The "pure" OOP approach, where method calls are used as messages to set or fetch aspects of the object, is usually does with getter and setter methods like: x = o.getX() o.setX(9) People use get and set methods, not because it's somehow morally wrong to expose attributes directly, but as a workaround for the lack of a language feature. In C++ and Java, different calling syntax is required for direct access and access mediated by methods, so if you start out exposing something directly and then change your mind, all the code using it has to be changed. For this reason, people got into the habit of wrapping everything in get and set methods from the beginning, "just in case". Python doesn't have this problem -- you can turn an attribute into a property at any time, and nothing else needs to change. So get and set methods are unnecessary and actively discouraged in Python. (C#, if I understand correctly, gets this sort of half-right. You can turn an attribute into a property, and the calling *source* doesn't change, but it all has to be recompiled -- which kind of defeats the purpose.) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: conceptual problem (was: A beginning beginner's question about input, output and . . .
On 13Jan2021 10:37, songbird wrote: > my momentary conceptual problem is that to me OOP means >being able to encapsulate data structures and code from >other parts of the program, but to me it doesn't look like >that is how python is designed. this is probably a complete >aside to this whole thread and perhaps even this newsgroup >so i'll subthread this. Python allows you to avoid mucking with the object internals from outside. But it doesn't prevent it. So you can (and often should) adopt an OOP approach - it reduces the dependencies between your classes, with the benefits that brings. The "pure" OOP approach, where method calls are used as messages to set or fetch aspects of the object, is usually does with getter and setter methods like: x = o.getX() o.setX(9) In Python this is less common. Simple things like that which do not intrude much on the conceptual model (i.e. if all such things will have an "X") are usually exposed as a public attribute which you can get or set directly: x = o.x o.x = 9 "Public" attributes in Python are just a convention: we name "private" attributes with a leading underscore and "public" attributes with leading letters and expect people using our classes to behave well. Sometime we _don't_ have a plain old attribute "x", but we do have a property of the object looking like it. Then you can implement something which looks like an attribute from outside: @property def x(self): # "x" if a derived value return self._a + self._b @x.setter def x(self, new_x): # setting "x" gets split between _a and _b x2 = x / 3 self._a = x2# put some in _a self._b = x - x2# put the rest in _b # you can still do this, but it calls methods now x = o.x o.x = 9 So Python supports OOP practices but doesn't enforce them. Adopt the degree of discipline you think best. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
conceptual problem (was: A beginning beginner's question about input, output and . . .
Chris Angelico wrote: ...projects that fade... > That's not really something Python can ever control, but I can say > with some confidence that the big libraries like Qt and GTK are going > to adapt, one way or another. And perhaps more importantly: Neither > input()/print() nor web applications is going *anywhere*. You are > ALWAYS going to have those two as options. :) i hope so. :) at the moment i've only done things with GTK and pyglet. since i am way too new at python i can't say the code is pretty, but it does work. my momentary conceptual problem is that to me OOP means being able to encapsulate data structures and code from other parts of the program, but to me it doesn't look like that is how python is designed. this is probably a complete aside to this whole thread and perhaps even this newsgroup so i'll subthread this. songbird -- https://mail.python.org/mailman/listinfo/python-list
