Create an instance of a python object immediately after defining its class

In a large python project (openerp), I come across the following pattern several times:

The module defines a class with its own methods. Then, in the same module and immediately after the class definition, an instance of the class is created, which is then called from other modules.

# in module_A.py: class ClassA(object): def __init__(self, default="Hello world!"): self.default = default def my_method(self, data): print self.default print data object_a = ClassA() 

It’s easier for me to define methods as functions of a module, without overloading the class:

 # in module_B.py: default = "Hello world!" def my_method(data): print default print data 

Seen from other modules, usage is very similar:

 from module_a import object_a as prefix prefix.my_method("I'm so objective!") 

vs

 import module_b as prefix prefix.my_method("I'm so modular!") 

Is there any justification to prefer pattern A over pattern B? Or is pattern B more pythonic?

+4
source share
2 answers

Sometimes you want different clients to be able to use your module with different settings so that they do not conflict with each other. For example, the Python random module provides many random number generation functions that are actually associated with the hidden instance method random . Most users do not care about which algorithm generates their random numbers, or other modules requesting random numbers will change the sequence. However, users who really care can get their own random object and generate sequences of random numbers that will not be affected by other modules requesting random numbers.

Sometimes, something global can now not always be global. For example, if you are working with planetary RTS, you might have the Planet class with one instance, because the battle only takes place on one planet. However, you do not want to exclude the possibility of creating something like Planetary Destruction, a battle that extends across all solar systems, and discarding asteroids in the form of a superweapon. If you get rid of the Planet class and execute its methods and attributes at the module level, it will be much more difficult to return and add more planets later.

Sometimes, it is more readable for objects to do things instead of modules. For example, suppose the joebob module defines two objects, evil_overlord_bob and good_guy_joe .

 class Bob(object): def slaughter_everything(self): print "Muahahaha! Die for my amusement!" class Joe(object): def stop_bob(self): print "I won't let you hurt those innocents!" evil_overlord_bob = Bob() good_guy_joe = Joe() 

Suppose Bob and Joe are very unique people. It is inconceivable that you want to create another object, similar to Bob or Joe. In this case, you can move slaughter_everything and stop_bob to the module level and completely get rid of the Bob and Joe classes and objects. However, then you will write

 joebob.slaughter_everything() joebob.stop_bob() 

It’s much clearer what happens if you can say

 evil_overlord_bob.slaughter_everything() good_guy_joe.stop_bob() 

even if you never need to create a brother instance with the same evil brother greg_the_fleshripper .

+3
source

Among other advantages, using classes allows you to use introspection in instances, which you cannot do with functions.

More generally, both approaches are pythons. Using one of the others really depends on the type of project (small / large, with / without GUI, ...)

0
source

Source: https://habr.com/ru/post/1492372/


All Articles