summaryrefslogtreecommitdiffstats
path: root/PLAN.txt
diff options
context:
space:
mode:
authorGuido van Rossum <guido@python.org>2001-10-26 04:31:54 (GMT)
committerGuido van Rossum <guido@python.org>2001-10-26 04:31:54 (GMT)
commitb016da3b8391b7401afd95f2c90f5073976c475b (patch)
tree2b177b5331a4737cfd522aeb89ad81eb75b8b8f1 /PLAN.txt
parent6661be3bedf7ad0da8d33487672a227eb6bee6f1 (diff)
downloadcpython-b016da3b8391b7401afd95f2c90f5073976c475b.zip
cpython-b016da3b8391b7401afd95f2c90f5073976c475b.tar.gz
cpython-b016da3b8391b7401afd95f2c90f5073976c475b.tar.bz2
Update. __dict__ assignment done. Reorder remaining "to do" items by
priority. Add tp_cache; add some comments to others.
Diffstat (limited to 'PLAN.txt')
-rw-r--r--PLAN.txt29
1 files changed, 22 insertions, 7 deletions
diff --git a/PLAN.txt b/PLAN.txt
index 4eb78a7..cdae04c 100644
--- a/PLAN.txt
+++ b/PLAN.txt
@@ -1,30 +1,45 @@
Project: core implementation
****************************
-Still to do
------------
-
-Add __del__ handlers?
+Still to do (by priority)
+-------------------------
-Allow assignment to __bases__ and __dict__?
+Add __del__ handlers? I asked for a motivation on python-dev and
+nobody piped up. Yet I expect it will be asked for later. Are there
+GC issues? Doesn't the GC make an exception for classic classes with
+a __del__ handler?
Support mixed multiple inheritance from classic and new-style classes?
+That would be cool and make new-style classes much more usable (it
+would remove most of the reasons not to use them for new projects).
+How hard would this be?
+
+Do something with the tp_cache slot? This is (was?) intended to cache
+all the class attributes from all base classes; a key would be deleted
+when the base class attribute is. But the question is, are the
+savings worth it? So I may not do this.
Check for conflicts between base classes. I fear that the rules used
to decide whether multiple bases have conflicting instance variables
aren't strict enough. I think that sometimes two different classes
-adding __dict__ may be incompatible after all.
+adding __dict__ may be incompatible after all. (I may not do this.
+Who cares.)
Check for order conflicts. Suppose there are two base classes X and
Y. Suppose class B derives from X and Y, and class C from Y and X (in
that order). Now suppose class D derives from B and C. In which
order should the base classes X and Y be searched? This is an order
conflict, and should be disallowed; currently the test for this is not
-implemented.
+implemented. (I may not do this. Who cares.)
+
+Allow assignment to __bases__? (I don't think there's a demand for
+this.)
Done (mostly)
-------------
+Assignment to __dict__.
+
More performance work -- one particular test, test_descr.inherits(),
is still about 50% slower with dynamic classes. :-( The approach of
choice would be: