Lines Matching +full:merge +full:- +full:multiple
11 but it is still used in later versions -- including Python 3.
37 the official Python 2.3 home-page.*
40 -------------
42 *Felix qui potuit rerum cognoscere causas* -- Virgilius
66 Moreover, unless you make strong use of multiple inheritance and you
67 have non-trivial hierarchies, you don't need to understand the C3
69 you really want to know how multiple inheritance works, then this paper
75 1) Given a class C in a complicated multiple inheritance hierarchy, it
76 is a non-trivial task to specify the order in which methods are
90 C is simply the list [C, C1 , C2]. However, with multiple
120 .. code-block:: text
122 -----------
126 - X Y /
143 ------------------------------
168 Consider a class C in a multiple inheritance hierarchy, with C
173 *the linearization of C is the sum of C plus the merge of the
178 L[C(B1 ... BN)] = C + merge(L[B1] ... L[BN], B1 ... BN)
185 However, in general one has to compute the merge according to the following
190 of C and remove it from the lists in the merge, otherwise look at the
194 merge, Python 2.3 will refuse to create the class C and will raise an
197 This prescription ensures that the merge operation *preserves* the
200 disagreement discussed above) then the merge cannot be computed.
202 The computation of the merge is trivial if C has only one parent
205 L[C(B)] = C + merge(L[B],B) = C + L[B]
207 However, in the case of multiple inheritance things are more cumbersome
209 examples ;-)
212 --------
226 .. code-block:: text
229 ---
231 / --- \
235 --- --- --- |
237 --- --- --- |
241 --- --- |
243 --- --- |
246 ---
248 ---
260 L[B] = B + merge(DO, EO, DE)
263 compute ``merge(O,EO,E)``. Now O is not a good head, since it is in the
266 it and we are reduced to compute ``merge(O,O)`` which gives O. Therefore::
272 L[C] = C + merge(DO,FO,DF)
273 = C + D + merge(O,FO,F)
274 = C + D + F + merge(O,O)
279 L[A] = A + merge(BDEO,CDFO,BC)
280 = A + B + merge(DEO,CDFO,C)
281 = A + B + C + merge(DEO,DFO)
282 = A + B + C + D + merge(EO,FO)
283 = A + B + C + D + E + merge(O,FO)
284 = A + B + C + D + E + F + merge(O,O)
303 The only difference with the previous example is the change B(D,E) -->
307 .. code-block:: text
310 ---
312 / --- \
316 --- --- ---
318 --- --- ---
322 --- ---
324 --- ---
327 ---
329 ---
349 .. code-block:: text
360 L[C] = C + merge(AXYO, BYXO, AB)
361 = C + A + merge(XYO, BYXO, B)
362 = C + A + B + merge(XYO, YXO)
364 At this point we cannot merge the lists XYO and YXO, since X is in the
370 ----------------------------
386 .. code-block:: text
416 is quite non-intuitive and error prone. This is particularly true since
429 avoided, since it is unclear if F should override E or vice-versa.
433 fails when the merge::
435 merge(FO,EFO,FE)
440 The real solution is to design a non-ambiguous hierarchy, i.e. to derive
444 .. code-block:: text
457 least, less error-prone ones).
479 that ;-)
486 To prove that the MRO for classic classes is non-monotonic is rather
489 .. code-block:: text
513 unavoidable and inconsistencies shows up in every multiple inheritance
518 Pedroni, shows that the MRO of Python 2.2 is non-monotonic:
532 diagram ;-) ::
561 -------
567 not be reading a paper on the C3 method resolution order in multiple
568 inheritance hierarchies ;-) These three virtues taken all together (and
627 def merge(seqs):
634 for seq in nonemptyseqs: # find merge candidates among seq heads
646 return merge([[C]]+map(mro,C.__bases__)+[list(C.__bases__)])
662 ---------
664 .. [#] The thread on python-dev started by Samuele Pedroni:
665 https://mail.python.org/pipermail/python-dev/2002-October/029035.html