batavia
batavia copied to clipboard
beeware
Complete implementation of operations on standard types
Javascript has a specific set of allowed operator and operations. Python has a set of operators and operations as well. However, the two don't match exactly. For example, Javascript behavior for adding/multiplying with Strings leads to behaviour that is quite distinct to the behavior provided by Python.
In order to replicate Python behavior in Javascript, Python's logic for all the basic operations needs to be implemented in the Batavia support library.
The test suite contains around 10000 tests in the that are currently marked as "expected failures". These reflect an attempt to do "every operation between every base data type". The task: pick a data type, and write the implementation of one of the math operation or comparison operators.
The tests will pass (and become unexpected successes) when the output of Python code doing that operation is the same when run through CPython and Batavia - and I mean byte-identical, down to the text and punctuation of the error message if appropriate.
If you want to see an example of what is involved, check out the implementation of add for integers. If you have an int, Python will allows you to add an int or a float to it; all other types raise a TypeError. The list of operations on int that still need to be implemented can be found here; if you add a new operation, delete the line that corresponds to that test, and the test will report as a pass, rather than an expected fail.
Ops. I guess test_floor_divide_str got resolved by @wlmiller on issue #67 I will pick something else to work on.
I'm sorry about that - I should have more carefully checked what was already being worked on.
For what it's worth, tackling these operations one at a time for each pair probably isn't the best way to go about it. For example, if you resolve test_floor_divide_str for string, you're very likely to also resolve floor_divide tests for many other combinations of types (in particular combinations which can't be floor_divided, e.g. string // tuple, list // dict, etc.).
In #67 I set out to implement the abs builtin and ended up resolving a ton of other tests along the way, including dozens of the tests in datatypes.
A more natural division is by operation. For example, resolving all of the floor_divide tests where both types have been implemented is a very reasonable chunk to work on. You could divide it further - e.g. floor_divide where both sides are numbers or floor_divide for combinations that will result in TypeErrors. Anything smaller than that is probably a pretty unnatural way to split things up.
No worries! I saw your implementation and there's no way I could have accomplished that. :sweat_smile: Good job!
Working on str in-place addition to str (test_add_str in InplaceStrOperationTests)
Working on InplaceStrOperationTests test_modulo_none (and any other string modulo operations that throw the SyntaxError: can't assign to literal error; update: looks like all of them)
Working on batavia.type_name in Type.js. I'm extending it so that bytes, sets, etc return the correct name and not "Native Type"
Working on implementing batavia.builtins.set in order to get InplaceStrOperationTests test_modulo_set to work
