Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Commit eb9f384

Browse files
committed
Group some projects into "Done" and "To do". Get rid of Tim's merge
scratchpad -- the merge is long behind us.
1 parent 91ee798 commit eb9f384

1 file changed

Lines changed: 46 additions & 213 deletions

File tree

PLAN.txt

Lines changed: 46 additions & 213 deletions
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,40 @@
11
Project: core implementation
22
****************************
33

4-
Tasks:
5-
6-
Do binary operators properly. nb_add should try to call self.__add__
7-
and other.__radd__. I think I'll exclude base types that define any
8-
binary operator without setting the CHECKTYPES flag. *** This is
9-
done, AFAICT. Even supports __truediv__ and __floordiv__. ***
4+
Still to do
5+
-----------
106

117
Fix comparisons. There's some nasty stuff here: when two types are
128
not the same, and they're not instances, the fallback code doesn't
139
account for the possibility that they might be subtypes of a common
1410
base type that defines a comparison.
1511

12+
Check for conflicts between base classes. I fear that the rules used
13+
to decide whether multiple bases have conflicting instance variables
14+
aren't strict enough. I think that sometimes two different classes
15+
adding __dict__ may be incompatible after all.
16+
17+
Check for order conflicts. Suppose there are two base classes X and
18+
Y. Suppose class B derives from X and Y, and class C from Y and X (in
19+
that order). Now suppose class D derives from B and C. In which
20+
order should the base classes X and Y be searched? This is an order
21+
conflict, and should be disallowed; currently the test for this is not
22+
implemented.
23+
24+
Allow __class__ assignment.
25+
26+
Make __dynamic__ the default.
27+
28+
Add __del__ handlers.
29+
30+
Done (mostly)
31+
-------------
32+
33+
Do binary operators properly. nb_add should try to call self.__add__
34+
and other.__radd__. I think I'll exclude base types that define any
35+
binary operator without setting the CHECKTYPES flag. *** This is
36+
done, AFAICT. Even supports __truediv__ and __floordiv__. ***
37+
1638
Fix subtype_dealloc(). This currently searches through the list of
1739
base types until it finds a type whose tp_dealloc is not
1840
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
3254
there, and there may be some places where PyObject_IsSubclass() is
3355
called where PyType_IsSubtype() would be more appropriate. ***
3456

35-
Check for conflicts between base classes. I fear that the rules used
36-
to decide whether multiple bases have conflicting instance variables
37-
aren't strict enough. I think that sometimes two different classes
38-
adding __dict__ may be incompatible after all.
39-
40-
Check for order conflicts. Suppose there are two base classes X and
41-
Y. Suppose class B derives from X and Y, and class C from Y and X (in
42-
that order). Now suppose class D derives from B and C. In which
43-
order should the base classes X and Y be searched? This is an order
44-
conflict, and should be disallowed; currently the test for this is not
45-
implemented.
46-
4757
Clean up the GC interface. Currently, tp_basicsize includes the GC
4858
head size iff tp_flags includes the GC flag bit. This makes object
4959
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.
5464
I think I know of a way to fix the incompatibility (by switching to a
5565
different flag bit). *** Tim proposed a better idea: macros to access
5666
tp_basicsize while hiding the nastiness. This is done now, so I think
57-
the rest of this task needn't be done. ***
67+
the rest of this task needn't be done. *** *** Neil checked in a
68+
much improved version of his idea, and it's all squared away. ***
5869

5970
Make the __dict__ of types declared with Python class statements
6071
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.
109120
Project: loose ends and follow-through
110121
**************************************
111122

112-
Tasks:
113-
114-
Make more (most?) built-in types act as their own factory functions.
115-
116-
Make more (most?) built-in types subtypable -- with or without
117-
overridable allocation. *** This includes descriptors! It should be
118-
possible to write descriptors in Python, so metaclasses can do clever
119-
things with them. ***
123+
Still to do
124+
-----------
120125

121126
Exceptions should be types. This changes the rules, since now almost
122127
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
144149
this? It's additional work and not required for any of the other
145150
parts.
146151

152+
Done (mostly)
153+
-------------
154+
155+
Make more (most?) built-in types act as their own factory functions.
156+
*** Done for all reasonable built-in types. ***
157+
158+
Make more (most?) built-in types subtypable -- with or without
159+
overridable allocation. *** This includes descriptors! It should be
160+
possible to write descriptors in Python, so metaclasses can do clever
161+
things with them. *** *** Done for most reasonable built-in types,
162+
except for descriptors ***
163+
147164

148165
Project: making classes use the new machinery
149166
*********************************************
@@ -154,7 +171,8 @@ Try to get rid of all code in classobject.c by deferring to the new
154171
mechanisms. How far can we get without breaking backwards
155172
compatibility? This is underspecified because I haven't thought much
156173
about it yet. Can we lose the use of PyInstance_Check() everywhere?
157-
I would hope so!
174+
I would hope so! *** I'm dropping this goal for now -- classic
175+
classes will be 99% unchanged. ***
158176

159177

160178
Project: backwards compatibility
@@ -276,188 +294,3 @@ responses to the feedback. Give the community enough time to think
276294
over this complicated proposal. Provide the community with a
277295
prototype implementation to test. Try to do this *before* casting
278296
everything in stone!
279-
280-
MERGE BEGIN ****************************************************************
281-
Merge details (this section is Tim's scratchpad, but should help a lot if
282-
he dies of frustration while wrestling with CVS <0.9 wink>).
283-
----------------------------------------------------------------------------
284-
2001-08-01 Merging descr-branch back into trunk.
285-
286-
Tagged trunk about 22:05:
287-
cvs tag date2001-08-01 python
288-
289-
Merged trunk delta into branch:
290-
cvs -q -z3 up -j date2001-07-30 -j date2001-08-01 descr
291-
292-
No conflicts (! first time ever!) ... but problems with pythoncore.dsp.
293-
Resolved.
294-
295-
Rebuilt from scratch; ran all tests; checked into branch about 22:40.
296-
297-
Merged descr-branch back into trunk (SEE BELOW -- this specific way of
298-
doing it was a bad idea):
299-
300-
cvs -q -z3 up -j descr-branch python
301-
302-
34 conflicts. Hmm! OK, looks like every file in the project with an
303-
embedded RCS Id is "a conflict". Others make no sense, e.g., a dozen
304-
conflicts in dictobject.c, sometimes enclosing identical(!) blobs of
305-
source code. And CVS remains utterly baffled by Python type object decls.
306-
Every line of ceval.c's generator code is in conflict blocks ... OK,
307-
there's no pattern or sense here, I'll just deal with it.
308-
309-
Conflicts resolved; rebuilt from scratch; test_weakref fails. Didn't find
310-
an obvious reason and it was late, so committed it anyway. Tagged the
311-
trunk then with tag:
312-
313-
after-descr-branch-merge
314-
315-
Tracked the test_weakref failure to a botched conflict resolution in
316-
classobject.c; checked in a fix.
317-
318-
LATER: The merge should have been done via:
319-
320-
upd -j date2001-08-01 -j descr-branch python
321-
322-
instead. This would have caused only one conflict, a baffler in
323-
bltinmodule.c. It would have avoided the classobject.c error I made.
324-
Luckily, except for that one, we got to the same place in the end anyway,
325-
apart from a few curious tabs-vs-spaces differences.
326-
----------------------------------------------------------------------------
327-
2001-07-30
328-
329-
Doing this again while the expat and Windows installer changes are still
330-
fresh on my mind.
331-
332-
Tagged trunk about 23:50 EDT on the 29th:
333-
cvs tag date2001-07-30 python
334-
335-
Merged trunk delta into branch:
336-
337-
cvs -q -z3 up -j date2001-07-28 -j date2001-07-30 descr
338-
339-
2 conflicts, resolved.
340-
----------------------------------------------------------------------------
341-
2001-07-28
342-
343-
Tagged trunk about 00:31 EDT:
344-
cvs tag date2001-07-28 python
345-
346-
Merged trunk delta into branch:
347-
cvs -q -z3 up -j date2001-07-21 -j date2001-07-28 descr
348-
349-
4 conflicts, all RCS Ids. Resolved.
350-
----------------------------------------------------------------------------
351-
2001-07-21
352-
353-
Tagged trunk about 01:00 EDT:
354-
cvs tag date2001-07-21 python
355-
356-
Merged trunk delta into branch:
357-
cvs -q -z3 up -j date2001-07-17b -j date2001-07-21 descr
358-
359-
4 conflicts, mostly RCS Id thingies. Resolved.
360-
361-
Legit failure in new test_repr, because repr.py dispatches on the exact
362-
string returned by type(x). type(1L) and type('s') differ in descr-branch
363-
now, and repr.py didn't realize that, falling back to the "unknown type"
364-
case for longs and strings. Repaired descr-branch repr.py.
365-
----------------------------------------------------------------------------
366-
2001-07-19
367-
368-
Removed the r22a1-branch tag (see next entry). Turns out Guido did add a
369-
r22a1 tag, so the r22a1-branch tag served no point anymore.
370-
----------------------------------------------------------------------------
371-
2001-07-18 2.2a1 releaase
372-
373-
Immediately after the merge just below, I tagged descr-branch via
374-
375-
cvs tag r22a1-branch descr
376-
377-
Guido may or may not want to add another tag here (? maybe he wants to do
378-
some more Unix fiddling first).
379-
----------------------------------------------------------------------------
380-
2001-07-17 building 2.2a1 release, from descr-branch
381-
382-
Tagged trunk about 22:00 EDT, like so:
383-
cvs tag date2001-07-17b python
384-
385-
Merged trunk delta into branch via:
386-
cvs -q -z3 up -j date2001-07-17a -j date2001-07-17b descr
387-
----------------------------------------------------------------------------
388-
2001-07-17
389-
390-
Tagged trunk about 00:05 EDT, like so:
391-
cvs tag date2001-07-17a python
392-
393-
Merged trunk delta into branch via:
394-
cvs -q -z3 up -j date2001-07-16 -j date2001-07-17a descr
395-
----------------------------------------------------------------------------
396-
2001-07-16
397-
398-
Tagged trunk about 15:20 EDT, like so:
399-
cvs tag date2001-07-16 python
400-
401-
Guido then added all the other dist/ directories to descr-branch from that
402-
trunk tag.
403-
404-
Tim then merged trunk delta into the branch via:
405-
cvs -q -z3 up -j date2001-07-15 -j date2001-07-16 descr
406-
----------------------------------------------------------------------------
407-
2001-07-15
408-
409-
Tagged trunk about 15:44 EDT, like so:
410-
cvs tag date2001-07-15 python
411-
412-
Merged trunk delta into branch via:
413-
cvs -q -z3 up -j date2001-07-13 -j date2001-07-15 descr
414-
415-
Four files with conflicts, all artificial RCS Id & Revision thingies.
416-
Resolved and committed.
417-
----------------------------------------------------------------------------
418-
2001-07-13
419-
420-
Tagged trunk about 22:13 EDT, like so:
421-
cvs tag date2001-07-13 python
422-
423-
Merged trunk delta into branch via:
424-
cvs -q -z3 up -j date2001-07-06 -j date2001-07-13 descr
425-
426-
Six(!) files with conflicts, mostly related to NeilS's generator gc patches.
427-
Unsure why, but CVS seems always to think there are conflicts whenever a
428-
line in a type object decl gets changed, and the conflict marking seems
429-
maximally confused in these cases. Anyway, since I reviewed those patches
430-
on the trunk, good thing I'm merging them, and darned glad it's still fresh
431-
on my mind.
432-
433-
Resolved the conflicts, and committed the changes in a few hours total.
434-
----------------------------------------------------------------------------
435-
2001-07-07
436-
437-
Merge of trunk tag date2001-07-06 into descr-branch, via
438-
cvs -q -z3 up -j date2001-07-06 mergedescr
439-
was committed on 2001-07-07.
440-
441-
Merge issues:
442-
443-
(all resolved -- GvR)
444-
----------------------------------------------------------------------------
445-
2001-07-06
446-
447-
Tagged trunk a bit after midnight, like so:
448-
449-
C:\Code>cvs tag date2001-07-06 python
450-
cvs server: Tagging python
451-
cvs server: Tagging python/dist
452-
cvs server: Tagging python/dist/src
453-
T python/dist/src/.cvsignore
454-
T python/dist/src/LICENSE
455-
T python/dist/src/Makefile.pre.in
456-
T python/dist/src/README
457-
... [& about 3000 lines more] ...
458-
459-
This is the first trunk snapshot to be merged into the descr-branch.
460-
Gave it a date instead of a goofy name because there's going to be more
461-
than one of these, and at least it's obvious which of two ISO dates comes
462-
earlier. These tags should go away after all merging is complete.
463-
MERGE END ******************************************************************

0 commit comments

Comments
 (0)