Run CPython's test_bool.py via unittest #824
Conversation
Codecov Report
@@ Coverage Diff @@
## master #824 +/- ##
==========================================
- Coverage 63.17% 63.12% -0.06%
==========================================
Files 84 85 +1
Lines 13894 13919 +25
Branches 3077 3078 +1
==========================================
+ Hits 8778 8786 +8
- Misses 3112 3127 +15
- Partials 2004 2006 +2
Continue to review full report at Codecov.
|
|
Only 13 of the 28 tests in test_bool.py actually pass, but that is good for this stage. |
|
I have added a Python script that displays the diff between the files that we have copied over from CPython, and the original files within the CPython source repository. Hopefully, this will allow us to keep track of the changes we make to them to ensure we don't diverge too much. |
|
This is awesome work, thank you! I think there's a bit too much in here for a single PR though, making it a bit hard to review. Could we get some of this split up a bit: rustpython fixes, addition of cpython library code, creation of test harness. I'm quite scared about copying code from cpython, especially when we then go on to patch the code. Is there an alternative to maintaining a fork of the cpython stdlib? Are we preferring it to ouroboros / maintaining a fork of parts of both? Is it possible to work off a checkout of one 0or the other? (I've been mostly staying out of the stdlib side of things so not sure exactly where this is going.) |
|
Yeah, this is way too huge. Looks like it has quite a lot of hacks and commented code sprinkled in, that'd be hard to sort out later. Mixing library code from CPython and ouroboros will get really messy really fast too. Anyway, I actually was also experimenting with moving |
|
This is a great step! Nice job! I propose splitting this work up into sizeable pieces, and merge the work one by one, as adrian suggested. I consider this PR as a proof of concept from which we can draw. Another note, I feel we should seperate tests using the standard library in a different folder than the test snippets. This way, we can run the test snippets without any standard library what so ever. What do you say? |
|
Another question, should we consider creating a new attempt along the same lines of ouroboros? |
|
Ok, I will split this PR up more. I approached this as more of a proof of concept to see where our shortcomings are. Over time once we fix these shortcomings we could move to use CPython standard library directly. But until then we need a place to make changes to the standard library to work around issues. But any ideas are welcome to how to make this work short and long term. @windelbouwman Possibly, but one of the issues I discovered was our import machinery was lacking. Fortunately, |
parts of _collections_abc we can't parse or run yet.
standard lib module to get around unimplemented features
tests/cpython_tests/, and their respective files in the CPython source repo. Also reverted a couple of changes in standard library files that are no longer needed.
8fb2ecf to
e42b2d6
Compare
RustPython changes for #824
|
I don't think having some logic for importing in importlib would be a problem. In fact, I think it is probably good to implement some specifics in python itself. As I understood, a lot of how python works, is actually implemented in python itself. Notable examples of this are the importing scheme and the REPL. |
|
Do you think this could be closed now @Skinny121? I think now we have a clearer view of what we want to do in order to run |
|
Yes, agree, we are making good progress towards being able to run |
I have managed to run the test_bool.py using unittest on RustPython.
I have copied the unittest package and its standard library dependencies over from CPython, and the pure python version of itertools.py from https://github.com/beeware/ouroboros.
Again I had to make changes to some of the standard library files to make unittest work. I had to make quite significant changes to unittest itself, but apart from disabling printing of tracebacks, none of the changes should affect the functionality of the library much. Note only limited functionality of unittest actually works at this stage.
In addition to some of my recent PR I have made the following changes to RustPython itself:
import unittest.case. This isn't implemented properly but is a hack to get importing of those to happen.function.__call__io.IOBase.flush_threadmoduletypes.MethodTypesys.internandsys.warnoptionsclassmethodhave a dict by default.This PR includes #817.