[pypy-dev] incomplete builtin modules policy

[holger krekel]

Hi Samuele, 

On Mon, May 09, 2005 at 00:29 +0200, Samuele Pedroni wrote:
> Hi, we had failures re-appear for core tests because of some inprogress 
> but still incomplete reimplementation of builtin modules got exposed. 
> This is a problem because we can be changing things for example about 
> the object model (objspace/std...) that are more related to the current 
> core goal and we would like as few as possible unrelated failures to 
> make it easy to spot failures produced by related changes and in general 
> to track problems down.
> 
> As things are now implemented if a module _codecs or binascii is in 
> pypy/lib it will be used even if the corresponding module is listed as 
> needing faking in sys2/state.py, that means pypy/lib takes precedence 
> over faking listing.

What about adding a '--unstable' switch both to pypy and to
py.test which would cause pypy to load modules from pypy/lib/
no matter what and otherwise (by default) would load
stable/faked modules as specified in some list or
dictionary?  Prefixes like 'inprogress_' or 'unstable_' are not
that nice because that makes testing from lib/test2 slightly
inconvenient although that's not too big a deal, probably. 

On a side note, it might make sense to generally advise 
for our pypy/lib reimplementations to convert the according
CPython regression tests to the py.test model (with Laura's conversion
tool) because they would run fast and nice on CPython level. 

    holger