more on 2.2 algo: > > >>> cpl.ex5(globals()) > > class a(object): pass > > class b(object): pass > > class c(object): pass > > class x(a): pass > > class y(a): pass > > class z(x,b,y,c): pass > > >>> cpl.names(z.__mro__) # just the class names, real 2.2 mro algo > > ['z', 'x', 'y', 'a', 'b', 'c', 'object'] now b is there, but a simple substitution will change things radically: >>> cpl.ex5perturb(globals()) class a(object): pass class b(object): pass class c(object): pass class x(a): pass class y(a): pass class y_b(b,y): pass class z(x,y_b,c): pass >>> cpl.names(z.__mro__) ['z', 'x', 'y_b', 'b', 'y', 'a', 'c', 'object'] instead of inheriting directly from b and y, z inherits from y_b that inherits from both. Now b is between x and a. > > >>> cpl.ex9(globals()) > > class a(object): pass > > class b(object): pass > > class c(object): pass > > class d(object): pass > > class e(object): pass > > class k1(a,b,c): pass > > class k2(d,b,e): pass > > class k3(d,a): pass > > class z(k1,k2,k3): pass > > >>> cpl.names(z.__mro__) > > ['z', 'k1', 'k3', 'a', 'k2', 'd', 'b', 'c', 'e', 'object'] > > I think this one *does* have an order conflict, and in that case all > bets are off about the book's algo. If you look at k1 and k2, clearly > d must come after a; yet k3 wants it after a. > yes but for class z(k3,k1,k2) the conflict would go away. It's not intuitive nor stable. regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4