Group some projects into "Done" and "To do". Get rid of Tim's merge

scratchpad -- the merge is long behind us.

1 files changed, 46 insertions, 213 deletions

diff --git a/PLAN.txt b/PLAN.txt
index 23f4894..559b125 100644
--- a/PLAN.txt
+++ b/PLAN.txt
@@ -1,18 +1,40 @@
 Project: core implementation
 ****************************
 
-Tasks:
-
-Do binary operators properly.  nb_add should try to call self.__add__
-and other.__radd__.  I think I'll exclude base types that define any
-binary operator without setting the CHECKTYPES flag.  *** This is
-done, AFAICT.  Even supports __truediv__ and __floordiv__. ***
+Still to do
+-----------
 
 Fix comparisons.  There's some nasty stuff here: when two types are
 not the same, and they're not instances, the fallback code doesn't
 account for the possibility that they might be subtypes of a common
 base type that defines a comparison.
 
+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.
+
+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.
+
+Allow __class__ assignment.
+
+Make __dynamic__ the default.
+
+Add __del__ handlers.
+
+Done (mostly)
+-------------
+
+Do binary operators properly.  nb_add should try to call self.__add__
+and other.__radd__.  I think I'll exclude base types that define any
+binary operator without setting the CHECKTYPES flag.  *** This is
+done, AFAICT.  Even supports __truediv__ and __floordiv__. ***
+
 Fix subtype_dealloc().  This currently searches through the list of
 base types until it finds a type whose tp_dealloc is not
 subtype_dealloc.  I think this is not safe.  I think the alloc/dealloc
@@ -32,18 +54,6 @@ appropriately.  For now, the old "abstract subclass" test is still
 there, and there may be some places where PyObject_IsSubclass() is
 called where PyType_IsSubtype() would be more appropriate. ***
 
-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.
-
-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.
-
 Clean up the GC interface.  Currently, tp_basicsize includes the GC
 head size iff tp_flags includes the GC flag bit.  This makes object
 size math a pain (e.g. to see if two object types have the same
@@ -54,7 +64,8 @@ that improves the API in this area, but it's backwards incompatible.
 I think I know of a way to fix the incompatibility (by switching to a
 different flag bit).  *** Tim proposed a better idea: macros to access
 tp_basicsize while hiding the nastiness.  This is done now, so I think
-the rest of this task needn't be done. ***
+the rest of this task needn't be done. ***  *** Neil checked in a
+much improved version of his idea, and it's all squared away. ***
 
 Make the __dict__ of types declared with Python class statements
 writable -- only statically declared types must have an immutable
@@ -109,14 +120,8 @@ More -- I'm sure new issues will crop up as we go.
 Project: loose ends and follow-through
 **************************************
 
-Tasks:
-
-Make more (most?) built-in types act as their own factory functions.
-
-Make more (most?) built-in types subtypable -- with or without
-overridable allocation.  *** This includes descriptors!  It should be
-possible to write descriptors in Python, so metaclasses can do clever
-things with them. ***
+Still to do
+-----------
 
 Exceptions should be types.  This changes the rules, since now almost
 anything can be raised (as maybe it should).  Or should we strive for
@@ -144,6 +149,18 @@ PyArg_ParseTupleAndKeywords() currently requires.)  But should we do
 this?  It's additional work and not required for any of the other
 parts.
 
+Done (mostly)
+-------------
+
+Make more (most?) built-in types act as their own factory functions.
+*** Done for all reasonable built-in types. ***
+
+Make more (most?) built-in types subtypable -- with or without
+overridable allocation.  *** This includes descriptors!  It should be
+possible to write descriptors in Python, so metaclasses can do clever
+things with them. *** *** Done for most reasonable built-in types,
+except for descriptors ***
+
 
 Project: making classes use the new machinery
 *********************************************
@@ -154,7 +171,8 @@ Try to get rid of all code in classobject.c by deferring to the new
 mechanisms.  How far can we get without breaking backwards
 compatibility?  This is underspecified because I haven't thought much
 about it yet.  Can we lose the use of PyInstance_Check() everywhere?
-I would hope so!
+I would hope so!  *** I'm dropping this goal for now -- classic
+classes will be 99% unchanged. ***
 
 
 Project: backwards compatibility
@@ -276,188 +294,3 @@ responses to the feedback.  Give the community enough time to think
 over this complicated proposal.  Provide the community with a
 prototype implementation to test.  Try to do this *before* casting
 everything in stone!
-
-MERGE BEGIN ****************************************************************
-Merge details (this section is Tim's scratchpad, but should help a lot if
-he dies of frustration while wrestling with CVS <0.9 wink>).
-----------------------------------------------------------------------------
-2001-08-01  Merging descr-branch back into trunk.
-
-Tagged trunk about 22:05:
-    cvs tag date2001-08-01 python
-
-Merged trunk delta into branch:
-    cvs -q -z3 up -j date2001-07-30 -j date2001-08-01 descr
-
-No conflicts (! first time ever!) ... but problems with pythoncore.dsp.
-Resolved.
-
-Rebuilt from scratch; ran all tests; checked into branch about 22:40.
-
-Merged descr-branch back into trunk (SEE BELOW -- this specific way of
-doing it was a bad idea):
-
-    cvs -q -z3 up -j descr-branch python
-
-34 conflicts.  Hmm!  OK, looks like every file in the project with an
-embedded RCS Id is "a conflict".  Others make no sense, e.g., a dozen
-conflicts in dictobject.c, sometimes enclosing identical(!) blobs of
-source code.  And CVS remains utterly baffled by Python type object decls.
-Every line of ceval.c's generator code is in conflict blocks ... OK,
-there's no pattern or sense here, I'll just deal with it.
-
-Conflicts resolved; rebuilt from scratch; test_weakref fails.  Didn't find
-an obvious reason and it was late, so committed it anyway.  Tagged the
-trunk then with tag:
-
-    after-descr-branch-merge
-
-Tracked the test_weakref failure to a botched conflict resolution in
-classobject.c; checked in a fix.
-
-LATER:  The merge should have been done via:
-
-    upd -j date2001-08-01 -j descr-branch python
-
-instead.  This would have caused only one conflict, a baffler in
-bltinmodule.c.  It would have avoided the classobject.c error I made.
-Luckily, except for that one, we got to the same place in the end anyway,
-apart from a few curious tabs-vs-spaces differences.
-----------------------------------------------------------------------------
-2001-07-30
-
-Doing this again while the expat and Windows installer changes are still
-fresh on my mind.
-
-Tagged trunk about 23:50 EDT on the 29th:
-    cvs tag date2001-07-30 python
-
-Merged trunk delta into branch:
-
-    cvs -q -z3 up -j date2001-07-28 -j date2001-07-30 descr
-
-2 conflicts, resolved.
-----------------------------------------------------------------------------
-2001-07-28
-
-Tagged trunk about 00:31 EDT:
-    cvs tag date2001-07-28 python
-
-Merged trunk delta into branch:
-    cvs -q -z3 up -j date2001-07-21 -j date2001-07-28 descr
-
-4 conflicts, all RCS Ids.  Resolved.
-----------------------------------------------------------------------------
-2001-07-21
-
-Tagged trunk about 01:00 EDT:
-    cvs tag date2001-07-21 python
-
-Merged trunk delta into branch:
-    cvs -q -z3 up -j date2001-07-17b -j date2001-07-21 descr
-
-4 conflicts, mostly RCS Id thingies.  Resolved.
-
-Legit failure in new test_repr, because repr.py dispatches on the exact
-string returned by type(x).  type(1L) and type('s') differ in descr-branch
-now, and repr.py didn't realize that, falling back to the "unknown type"
-case for longs and strings.  Repaired descr-branch repr.py.
-----------------------------------------------------------------------------
-2001-07-19
-
-Removed the r22a1-branch tag (see next entry).  Turns out Guido did add a
-r22a1 tag, so the r22a1-branch tag served no point anymore.
-----------------------------------------------------------------------------
-2001-07-18  2.2a1 releaase
-
-Immediately after the merge just below, I tagged descr-branch via
-
-    cvs tag r22a1-branch descr
-
-Guido may or may not want to add another tag here (? maybe he wants to do
-some more Unix fiddling first).
-----------------------------------------------------------------------------
-2001-07-17  building 2.2a1 release, from descr-branch
-
-Tagged trunk about 22:00 EDT, like so:
-    cvs tag date2001-07-17b python
-
-Merged trunk delta into branch via:
-    cvs -q -z3 up -j date2001-07-17a -j date2001-07-17b descr
-----------------------------------------------------------------------------
-2001-07-17
-
-Tagged trunk about 00:05 EDT, like so:
-    cvs tag date2001-07-17a python
-
-Merged trunk delta into branch via:
-    cvs -q -z3 up -j date2001-07-16 -j date2001-07-17a descr
-----------------------------------------------------------------------------
-2001-07-16
-
-Tagged trunk about 15:20 EDT, like so:
-    cvs tag date2001-07-16 python
-
-Guido then added all the other dist/ directories to descr-branch from that
-trunk tag.
-
-Tim then merged trunk delta into the branch via:
-    cvs -q -z3 up -j date2001-07-15 -j date2001-07-16 descr
-----------------------------------------------------------------------------
-2001-07-15
-
-Tagged trunk about 15:44 EDT, like so:
-    cvs tag date2001-07-15 python
-
-Merged trunk delta into branch via:
-    cvs -q -z3 up -j date2001-07-13 -j date2001-07-15 descr
-
-Four files with conflicts, all artificial RCS Id & Revision thingies.
-Resolved and committed.
-----------------------------------------------------------------------------
-2001-07-13
-
-Tagged trunk about 22:13 EDT, like so:
-    cvs tag date2001-07-13 python
-
-Merged trunk delta into branch via:
-    cvs -q -z3 up -j date2001-07-06 -j date2001-07-13 descr
-
-Six(!) files with conflicts, mostly related to NeilS's generator gc patches.
-Unsure why, but CVS seems always to think there are conflicts whenever a
-line in a type object decl gets changed, and the conflict marking seems
-maximally confused in these cases.  Anyway, since I reviewed those patches
-on the trunk, good thing I'm merging them, and darned glad it's still fresh
-on my mind.
-
-Resolved the conflicts, and committed the changes in a few hours total.
-----------------------------------------------------------------------------
-2001-07-07
-
-Merge of trunk tag date2001-07-06 into descr-branch, via
-    cvs -q -z3 up -j date2001-07-06 mergedescr
-was committed on 2001-07-07.
-
-Merge issues:
-
-(all resolved -- GvR)
-----------------------------------------------------------------------------
-2001-07-06
-
-Tagged trunk a bit after midnight, like so:
-
-C:\Code>cvs tag date2001-07-06 python
-cvs server: Tagging python
-cvs server: Tagging python/dist
-cvs server: Tagging python/dist/src
-T python/dist/src/.cvsignore
-T python/dist/src/LICENSE
-T python/dist/src/Makefile.pre.in
-T python/dist/src/README
-... [& about 3000 lines more] ...
-
-This is the first trunk snapshot to be merged into the descr-branch.
-Gave it a date instead of a goofy name because there's going to be more
-than one of these, and at least it's obvious which of two ISO dates comes
-earlier.  These tags should go away after all merging is complete.
-MERGE END ******************************************************************