[pypy-dev] interface changes (would-have-been: builtin -- getting started)

[Laura Creighton]

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