Source

hotpy_2 / PLAN.txt

Diff from to

File PLAN.txt

 Project: core implementation
 ****************************
 
-Tasks:
+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 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.
-
 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
 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
 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
 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
 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
 *********************************************
 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
 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 ******************************************************************