|
1 | 1 | Project: core implementation |
2 | 2 | **************************** |
3 | 3 |
|
4 | | -Still to do |
5 | | ------------ |
6 | | - |
7 | | -Add __del__ handlers? |
| 4 | +Still to do (by priority) |
| 5 | +------------------------- |
8 | 6 |
|
9 | | -Allow assignment to __bases__ and __dict__? |
| 7 | +Add __del__ handlers? I asked for a motivation on python-dev and |
| 8 | +nobody piped up. Yet I expect it will be asked for later. Are there |
| 9 | +GC issues? Doesn't the GC make an exception for classic classes with |
| 10 | +a __del__ handler? |
10 | 11 |
|
11 | 12 | Support mixed multiple inheritance from classic and new-style classes? |
| 13 | +That would be cool and make new-style classes much more usable (it |
| 14 | +would remove most of the reasons not to use them for new projects). |
| 15 | +How hard would this be? |
| 16 | + |
| 17 | +Do something with the tp_cache slot? This is (was?) intended to cache |
| 18 | +all the class attributes from all base classes; a key would be deleted |
| 19 | +when the base class attribute is. But the question is, are the |
| 20 | +savings worth it? So I may not do this. |
12 | 21 |
|
13 | 22 | Check for conflicts between base classes. I fear that the rules used |
14 | 23 | to decide whether multiple bases have conflicting instance variables |
15 | 24 | aren't strict enough. I think that sometimes two different classes |
16 | | -adding __dict__ may be incompatible after all. |
| 25 | +adding __dict__ may be incompatible after all. (I may not do this. |
| 26 | +Who cares.) |
17 | 27 |
|
18 | 28 | Check for order conflicts. Suppose there are two base classes X and |
19 | 29 | Y. Suppose class B derives from X and Y, and class C from Y and X (in |
20 | 30 | that order). Now suppose class D derives from B and C. In which |
21 | 31 | order should the base classes X and Y be searched? This is an order |
22 | 32 | conflict, and should be disallowed; currently the test for this is not |
23 | | -implemented. |
| 33 | +implemented. (I may not do this. Who cares.) |
| 34 | + |
| 35 | +Allow assignment to __bases__? (I don't think there's a demand for |
| 36 | +this.) |
24 | 37 |
|
25 | 38 | Done (mostly) |
26 | 39 | ------------- |
27 | 40 |
|
| 41 | +Assignment to __dict__. |
| 42 | + |
28 | 43 | More performance work -- one particular test, test_descr.inherits(), |
29 | 44 | is still about 50% slower with dynamic classes. :-( The approach of |
30 | 45 | choice would be: |
|
0 commit comments