Fix some bugs in handler tutorial
This commit is contained in:
parent
f18d9d68b3
commit
59bb10e76a
1 changed files with 4 additions and 4 deletions
|
|
@ -24,7 +24,7 @@ class NameChanger:
|
|||
class MyObject(DefaultObject):
|
||||
@lazy_property:
|
||||
def namechange(self):
|
||||
return MyHandler(self)
|
||||
return NameChanger(self)
|
||||
|
||||
|
||||
obj = create_object(MyObject, key="test")
|
||||
|
|
@ -35,7 +35,7 @@ print(obj.key)
|
|||
>>> "test_extra"
|
||||
```
|
||||
|
||||
What happens here is that we make a new class `MyHandler`. We use the `@lazy_property` decorator to set it up - this means the handler will not be actually created until someone really wants to use it, by accessing `obj.namechange` later. The decorated `namechange` method returns the handler and makes sure to initialize it with `self` - this becomes the `obj` inside the handler!
|
||||
What happens here is that we make a new class `NameChanger`. We use the `@lazy_property` decorator to set it up - this means the handler will not be actually created until someone really wants to use it, by accessing `obj.namechange` later. The decorated `namechange` method returns the handler and makes sure to initialize it with `self` - this becomes the `obj` inside the handler!
|
||||
|
||||
We then make a silly method `add_to_key` that uses the handler to manipulate the key of the object. In this example, the handler is pretty pointless, but grouping functionality this way can both make for an easy-to-remember API and can also allow you cache data for easy access - this is how the `AttributeHandler` (`.attributes`) and `TagHandler` (`.tags`) works.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue