some next steps (was: Re: [pypy-dev] Release)

[Dinu Gherman]

holger krekel:

> Personally, i hope i will find some time to seriously improve
> the testing framework on various levels.  With PyPy, we begin to
> have lots of options and variants in testing our own code
> base, the standard python library's tests as well as testing
> translation targets and variants.

Being a fan of testing I'd like to suggest conducting some compara-
tive tests between CPython and PyPy, as well. At least I find stuff
like the following pretty "interesting". It's about using re for
splitting strings at very large substrings of some minimum length
(something I just used for processing AIFF audio files, the code
here is slightly simpler):

     Python 2.4 (#1, Feb  7 2005, 21:41:21)
     [GCC 3.3 20030304 (Apple Computer, Inc. build 1640)] on darwin
     Type "help", "copyright", "credits" or "license" for more 
information.
     >>>
     >>> import re
     >>> n = 'o'
     >>> l = int(1e5)
     >>> inp = "012" + n*l + "abc" + n*l + "xyz"
     >>> exp = ["012", "abc", "xyz"]
     >>> res = re.split(n+'{%d,%d}'%(l, l), inp)
     >>> exp == res
     False

vs.

     PyPy 0.7.0 in StdObjSpace on top of Python 2.4 (startupttime: 7.99 
secs)
     >>>
     >>>> import re
     >>>> n = 'o'
     >>>> l = int(1e5)
     >>>> inp = "012" + n*l + "abc" + n*l + "xyz"
     >>>> exp = ["012", "abc", "xyz"]
     >>>> res = re.split(n+'{%d,%d}'%(l, l), inp)
     >>>> exp == res
     True

There could be workarounds for this particular case, but the point is
that PyPy can be "correct" in places where CPython is not (here prob-
ably because of limitations of the re machinery). And because they'd
fail you would not expect to find such test cases in the "normal"
test suites...

In a way it's like saying "Look ma, I might be still bloody slow, but
eventually I'm getting to the right place!"

Dinu