Learn Python and all that

Over the past few days, I have discussed OOP with several friends in various ways: linghu, Frank, jin jian, xiao feng

People have different ideas about OOP, engineering and academic. From an application perspective, the engineering perspective is recommended: don't worry too much about how the interior works, just solve the problem at hand. However, for learners, if they only stay at the level of engineering (especially, the above friends are all heroes of engineering, they are not simply able to use, in fact, is a higher level of "no move is better than no move"), learners may feel a little not thorough. So, learners, especially beginners, should be aware of some internal reasons, but don't forget the purpose of the application in order to delve into the internal reasons. It seems that the coordination between the two is still a difficult thing to do. Don't worry, as the practice of the in-depth, will gradually have the experience.

Here are some common reasons to use OOP, based on "OOP in the eyes of a master" from MARK Lutz's "Learning Python."
  The & # 8226; Code reuse. This is simple (and the number one reason to use OOP). By supporting inheritance, classes allow you to program by customization instead of starting a project from scratch each time.
  The & # 8226; Encapsulation. Wrapping the implementation details behind the object interface isolates the impact of code changes on the user.
  The & # 8226; Structure. Class provides a new local scope that minimizes variable name conflicts. They also provide a natural place to write and find implementation code, and to manage object state.
  The & # 8226; Maintainability. Classes naturally facilitate code decomposition, which allows us to reduce redundancy. Support class structure and code reuse so that only one copy of the code needs to be modified at a time.
  The & # 8226; Consistency. Classes and inheritance implement common interfaces. This not only gives the code a uniform look and feel, but also simplifies debugging, understanding, and maintenance of the code.
  The & # 8226; Polymorphism. Polymorphism makes the code more flexible and has a wide range of applicability. (this seems to be an OOP property, not a reason to use it)
 
Anyway, class is a very important thing, when you learn, you must use more.

In addition, in the case of python2, there is something called new-style, which corresponds to the previous class, which is called classic. However, with Python3, there is no such difference, the two merge. It's just that in Python2, the two are different. This tutorial still does not cover the new type of questions in the basic part, if the reader is interested, you can find relevant information in GOOGLE, or as the course progresses, to the next stage to study.

Bound and unbound methods

If you remember, when we learned the methods of the class, we mentioned that the methods of the class are functions, except that this function behaves a little bit differently than the functions we learned before, like self. Of course, it doesn't have to be there, and you'll see that there's no self. Since methods, like functions, are essentially functions, then, the function part of the learning has been clear: functions are objects, therefore, class methods are also objects. As I said, some of the methods of the class can have self and some can't. In order to make the distinction, the following definition is further made:
  The & # 8226; Unbound class method object: no self
  The & # 8226; Bind instance method object: has self
 
Invokes the binding instance method object

>>> class MyClass:

...     def foo(self,text):

...         print text

... 

  Instance methods can be invoked in the following manner

>>> a = MyClass()       # Create class instance 

>>> a.foo('qiwsir.github.io')       # Invoking an instance method 

qiwsir.github.io

>>> a.foo

<bound method MyClass.foo of <__main__.MyClass instance at 0xb74495ac>>

  When this instance method is called, its data transfer flow, there's a graph in writing class two methods, which shows that in the method called above, the instance name a has actually been passed to self, which is the call binding instance method object, which has self.

The above call procedure can also be implemented as follows:

>>> a = MyClass()

>>> x = a.foo       # The instance a Sum method function foo Bind together 

>>> x

<bound method MyClass.foo of <__main__.MyClass instance at 0xb74495ac>>

>>> x("qiwsir.github.io")

qiwsir.github.io

  In the case of the above call, this is actually the equivalent of the decomposition action of the previous call procedure. So I'm going to bind instance a to the method function foo, and then I'm going to assign it to x, and then x is going to be like a simple function, and I'm going to pass in the arguments in that way. So the way to bind an instance to a method function is to use the dot notation (object.method_function)

Invokes an unbound class method object

A class method object is a method function (classname.method_function) that does not pass an instance

>>> a = MyClass()

>>> y = MyClass.foo     # There are no class calls 

>>> y

<unbound method MyClass.foo>

  With such a call, you get an unbound method object, but you must pass in the instance as the first argument, as shown below

>>> y(a,"qiwsir.github.io")

qiwsir.github.io

  Otherwise, report an error. Please pay special attention to the error message

>>> y("qiwsir.github.io")

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

TypeError: unbound method foo() must be called with MyClass instance as first argument (got str instance instead)

>>> 

  In programming practice, it seems like you're calling instance methods a little more.

docstring

When you're writing a program, you have to write the necessary captions, for no other reason than that your code is easy to understand, especially if the names of variables, functions, and classes are easy for anyone to understand.

Write a documentation string at the beginning of a function, class, or file, usually in triple quotes. The great advantage of writing this way is that you can see it using the help() function.

"""This is python lesson"""
def start_func(arg):

    """This is a function."""

    pass
class MyClass:

    """Thi is my class."""

    def my_method(self,arg):

        """This is my method."""

        pass

  Such documentation is required.

Of course, in programming, there's a lot of "#" notation. This is usually used to comment on parts.

Classes don't really end there, but I'm going to stop there for a moment. Judge by practice.