mirror of https://github.com/python/cpython
Group some projects into "Done" and "To do". Get rid of Tim's merge
scratchpad -- the merge is long behind us.
This commit is contained in:
Guido van Rossum
parent
91ee798892
commit
eb9f384c28
259
PLAN.txt
259
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 ******************************************************************
|
||||
|
|
|
|||
Loading…
Reference in New Issue