[Tutor] Why do I not get an error when I mistakenly type "humdrum.sigh_strenght" instead of the correct "humdrum.sigh_strength"?

[Cameron Simpson]

On 23Jan2016 01:52, boB Stepp <robertvstepp at gmail.com> wrote:
>On Fri, Jan 22, 2016 at 11:04 PM, Cameron Simpson <cs at zip.com.au> wrote:
>> On 22Jan2016 22:14, boB Stepp <robertvstepp at gmail.com> wrote:
>> All you're missing is realising that setting an attribute is not a special
>> operation.
>
>I guess no matter how new one is to OOP, one nevertheless brings one's
>preconceptions, however malformed, into the learning process.  In my
>case, one of mine was that once a class is coded, any given instance
>of a class is forevermore responsible for managing its *internals*, so
>that any change in these would be managed by the object when one of
>its (meant to be) publicly available methods is called.

That is the pure OO way; and you can do things that way in Python, though you 
can't _prevent_ direct access.  However, it isn't the common way with Python; 
generally with a Python class there are public attributes with ordinary names; 
outsiders can consult them but generally should not change them unless the doco 
says that is ok. "Internal" attributes which outsiders should not touch are 
general givens names starting with an underscore so that outsiders can know.

>In the case
>of attributes, I was thinking/expecting something like the following
>would have to be done:
>
>>>> class Dog(object):
>        def __init__(self, name, breed):
>            self.name = name
>            self.breed = breed
>            self.number_legs = 4
>            self.number_tails = 1
>            self.number_eyes = 2
>            self.attributes = {
>                'name': self.name,
>                'breed': self.breed,
>                'number of legs': self.number_legs,
>                'number of tails': self.number_tails,
>                'number of eyes': self.number_eyes}
>
>        def add_attribute(self, new_attribute_name, new_attribute_value):
>            self.new_attribute_name = new_attribute_name
>            self.new_attribute_value = new_attribute_value
>            self.attributes[self.new_attribute_name] = self.new_attribute_value
>
>        def show_attributes(self):
>            print("The object,", self.name, "has the following attributes:")
>            for attribute_name, attribute_value in self.attributes.items():
>                print(attribute_name, "=", attribute_value)
>
>>>> our_dog = Dog('Copper', 'beagle')
>>>> our_dog.show_attributes()
>The object, Copper has the following attributes:
>number of tails = 1
>number of legs = 4
>breed = beagle
>name = Copper
>number of eyes = 2
>>>> our_dog.add_attribute('unique marking', 'blue right eye')
>>>> our_dog.show_attributes()
>The object, Copper has the following attributes:
>number of legs = 4
>breed = beagle
>unique marking = blue right eye
>number of tails = 1
>name = Copper
>number of eyes = 2
>
>I suspect there are probably better ways to do what I am trying to
>demonstrate [I am trying to use a dict to simulate adding new instance
>variables after the fact.],

You're aware that most objects have a .__dict__ attribute containing the 
attributes? It is a dict, btw. So:

  class O(object):
    pass

  >>> o=O()
  >>> o.x=1
  >>> o.__dict__
  {'x': 1}

>perhaps with built-in functions that I
>have not read about yet.  But I hope my code illustrates my previous
>expectations.  I guess I was expecting that access to an object's
>internals would be more strictly regulated.  But, thinking about it, I
>already knew that even if name mangling is done for a method's name,
>it can still be directly accessed from outside of that object's class
>definition.

Yeah. If you mean .__blah methods and attributes, I used to use them but 
generally don't these days. They're more an aid to avoiding collisions when 
subclassing to my mind, but they're not bulletproff and the implicit mangling 
makes for confusion in my mind.

>But if I am understanding everyone's comments correctly, Python allows
>me write my classes in such a way, that public access to my object's
>internals is controlled, in the sense that Python has coding
>conventions that tell all of the quite intelligent, respectful,
>consenting adults that might use my code how I intend that code to be
>used.  And that I, despite my intentions, must respect that users of
>my code may have very valid reasons for deviating from my intentions.
>Have I captured the Pythonic spirit of what everyone has been trying
>to tell me?

Pretty much.

Alan will take you up on doing purer OO practices in Python.

Cheers,
Cameron Simpson <cs at zip.com.au>