Complete implementation of operations on standard types

[freakboy3742]

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.

[betojulio]

I will work on test_multiply_float for String

[winza83]

I'm still working on test_add_bool for string

[betojulio]

working on test_add_list

[betojulio]

working on test_add_none for string

[betojulio]

working on test_multiply_none for string

[betojulio]

working on test_unary_positive and test_unary_negative for string

[vyyyy]

working on test_subtract_str for String

[FlaviaBastos]

Working on test_floor_divide_str for string

[FlaviaBastos]

Ops. I guess test_floor_divide_str got resolved by @wlmiller on issue #67
I will pick something else to work on.

[wlmiller]

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.

[FlaviaBastos]

No worries!
I saw your implementation and there's no way I could have accomplished that. 😅 Good job!