In a message of Sat, 01 Mar 2003 06:55:27 +0100, Christian Tismer writes:

Hi friends,

as stated in my last message, I think that we suffer from a lack of "recipies" how to get started, and we are all eager to do some implementation.

I'd like to encourage everybody on this list to do get started, although we are probably defining interfaces "after the fact". That menas, you may write something up, but you will need to be aware that the interface might be changed.

This is not as bad as it sounds, it just means that you shouldn't worry about the interfaces too much, instead concentrate on the meat of the implementation.

Just to give you an example, I just discovered that "my" integer object happened to change without notice. On Armin's request, I dropped the "cmp" operator and implemented rich comparisons. Suddenly, I today see my if-then-else battery changed into six single functions. This is fine with me, although I had appreciated some notice about that change, either by private emails or by an automagic update magic from Subversion -- anyway, this doesn't matter so much.

This scares me a bit. I might write 2 functions one of which depends on the implementation of the other. I know that I should document that, but sometimes I am not really conscious that one depends on the other, until 'the other' changes, and ooops, 'the one' breaks. I'm afraid that this will happen here, plus we may thrash as people commit changes over each others changes because each is persuing an active development strategy which aren't leading to one harmonious whole, but as two different interpretations. Because we can do this, I would like it we started out with a way to load a collection of unit tests, which define 'C-Python- compliant' in such a way that you could develop as follows: (note this this uses make syntax. I am not demanding this, the Scons way, or the A-A-A way are all fine by me - I am using make as an example because I am familiar with it, nothing else) 1. Make a directory -- say trunk/src/pypy/objspace/lacobjspace 2. Copy basic makefile to there from some known location. 3. Then type make getunittests You will get a test suite made which includes all the unit tests we know we have to satisfy to make a compliant object space. This I think should be a bunch of separate files in a directory, not one big file. 4. Then you go get whatever modules you like from trunk/src/pypy/objspace/* and copy them into yoru directory. 5. Then you modify them, and write new ones. Writing new ones means writing new unit tests, which should come first IMHO 6. At some point you decide that you want to contribute your unittests to the project. This may be before you have your objects working exactly right -- the idea is to save the next guy from doing the same work twice even if you are working on different implementations of the same builtin. make donate-unittest unittestfile should work. What is important is that this just adds your unit test to the collection of tests, and doesn't replace somebody else's test. If you think that a test is _wrong_ that is a different matter. We may need a way to specify that in trunk/src/pypy/objspace/lacobjspace we _don't_ want Stephan's double tests15-20, since his doubles are made differently than mine, and those are to test that you get the correct tuple back, and mine aren't tuples at all. 7. At some point, you decide you want to let everybody see and use your code. You post a 'these are now working' note. I don't know if pypy-dev is the correct place for this. It is traditional to have a separate mailing list for checkins, which this sounds like. Maybe we need to use the issue tracker for this, though I like getting mail myself. Old habits and all that. Is this scheme too complicated? Comments, criticism, strongly desired ... Laura