File: PKG-INFO

package info (click to toggle)
python-peak.rules 0.5a1%2Br2713-1
  • links: PTS, VCS
  • area: main
  • in suites: buster, stretch
  • size: 632 kB
  • ctags: 658
  • sloc: python: 3,625; makefile: 29
file content (141 lines) | stat: -rw-r--r-- 5,521 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
Metadata-Version: 1.0
Name: prioritized-methods
Version: 0.2.2dev-20110830
Summary: An extension to PEAK-Rules to prioritize methods in order to to avoid AmbiguousMethods situations
Home-page: UNKNOWN
Author: Alberto Valverde Gonzalez
Author-email: alberto@toscat.net
License: MIT
Download-URL: http://toscawidgets.org/download
Description: This module provides four decorators:
        
          ``prioritized_when``
        
          ``prioritized_around``
        
          ``prioritized_before``
        
          ``prioritized_after``
        
        These behave like their ``peak.rules`` counterparts except that they accept an
        optional ``prio`` argument which can be used to provide a comparable object
        (usually an integer) that will be used to disambiguate
        situations in which more than rule applies to the given arguments and no rule
        is more specific than another. That is, situations in which an
        ``peak.rules.AmbiguousMethods`` would have been raised.
        
        This is useful for libraries which want to be extensible via generic functions
        but want their users to easily override a method without figuring out how to
        write a more specific rule or when it is not feasible.
        
        For example, TurboJson provides a ``jsonify`` function that looks like this::
        
            >>> def jsonify(obj):
            ...     "jsonify an object"
            
        
        And extends it so it can handle SqlAlchemy mapped classes in a way
        similar to this one::
        
        
            >>> from peak.rules import when
        
            >>> def jsonify_sa(obj):
            ...     print "You're a SA object and I'm going to jsonify you!"
        
            >>> when(jsonify, "hasattr(obj, 'c')")(jsonify_sa) # doctest: +ELLIPSIS
            <function jsonify_sa at ...>
        
            >>> class Person(object):
            ...     def __init__(self):
            ...         self.c = "im a stub"
        
            >>> jsonify(Person())
            You're a SA object and I'm going to jsonify you!
        
        So far so good, however, when a user of the library wants to override the built
        in implementation it can become quite hard since they have to write a more
        specific rule which can be tedious, for example::
        
            hasattr(self, 'c') and isinstance(obj, Person)
        
        Notice the ``hasattr`` test, even though ``isinstance(obj, Person)`` implies it,
        just to make it more specific than the built in, this gets more cumbersome the
        more complicated the expression becomes.
        
        Else this is what happens::
        
            >>> def jsonify_Person(obj):
            ...     print "No way, I'm going to jsonify you!"
        
            >>> when(jsonify, (Person,))(jsonify_Person) # doctest: +ELLIPSIS
            <function jsonify_Person at ...>
        
            >>> try:
            ...     jsonify(Person())
            ... except AmbiguousMethods:
            ...     print "I told you, gfs can sometimes be a pain"
            I told you, gfs can sometimes be a pain
        
        
        To remedy this situation ``prioritized_when`` can be used to provide an
        implementation that will override the one declared with ``when``::
        
            >>> def jsonify_Person2(obj):
            ...     print "No way, I'm going to jsonify you!"
        
            >>> prioritized_when(jsonify, (Person,))(jsonify_Person2) # doctest: +ELLIPSIS
            <function jsonify_Person2 at ...>
        
            >>> jsonify(Person())
            No way, I'm going to jsonify you!
        
        Notice that we didn't need a ``prio`` argument. This is because methods
        decorated with ``prioritized_when`` always override those that have been
        decorated with ``peak.rules.when``.
        
        Methods decorated with ``prioritized_when`` can also override other methods
        that have been decorated by the same decorator using the ``prio`` parameter,
        the one which compares greater wins, if both are equal
        ``AmbiguousMethods`` will be raised as usual.
        
            >>> def jsonify_Person3(obj):
            ...     print "Don't be so smart, I am, my prio is higher!"
        
            >>> prioritized_when(jsonify, (Person,), prio=1)(jsonify_Person3) # doctest: +ELLIPSIS
            <function jsonify_Person3 at ...>
        
            >>> jsonify(Person())
            Don't be so smart, I am, my prio is higher!
        
        For convenience, a ``generic`` decorator is provided too which behaves
        like ``peak.rules.dispatch.generic`` except that the ``when``,...,``after``
        decorators that will be bound as attributes of the decorated function will be
        prioritized::
        
            >>> @generic
            ... def f(n): pass
        
            >>> f(5)
            Traceback (most recent call last):
                ...
            NoApplicableMethods: ((5,), {})
            
        Add a default rule::
        
            >>> @f.when()
            ... def default_f(n):
            ...     return n
            >>> f(5)
            5
        
        Add a default rule that overrides the former::
        
            >>> @f.when(prio=1)
            ... def new_default_f(n):
            ...     return n+1
            >>> f(5)
            6
        
Keywords: PEAK rules generic functions dispatch
Platform: UNKNOWN