webassembly: Revert conversion of Python None to JavaScript null, and make dict proxy return undefined when key doesn't exist

[dpgeorge]

There are 3 related commits in this PR:

• Revert back to converting Python None to JavaScript null. This essentially reverts fa23e4b which made None convert to undefined. So now it's back to how it was before that commit, and Py None converts to JS null. That's consistent with how the json module converts these values.
• Create a special "undefined" type/instance for Python visibility. This corresponds exactly to JS undefined. It's accessible via js.undefined. Passing this from Py to JS, JS will receive undefined. And when JS passes undefined to Py, Py will see the proxy js.undefined value.
• Make proxy Py dicts return undefined to JS when JS looks up a key that doesn't exist (instead of raising KeyError). These semantics match better the JS behaviour of {} objects.

The first two changes mean the following:

• There's a one-to-one correspondence between Py None and JS null.
• There's a one-to-one correspondence between Py js.undefined and JS undefined.
• Conversion of these values matches the json module.

All three changes together mean that, given the following JavaScript function with an optional argument:

function withDefault({ value = 'OK' } = {}) {
  console.log(value);
}

the JavaScript and Python code to call this function have equivalent behaviour, namely, in JavaScript:

withDefault();
withDefault({});
withDefault({ value: null });
withDefault({ value: undefined });

and in Python:

js.withDefault()
js.withDefault({})
js.withDefault({"value": None})
js.withDefault({"value": js.undefined})

[dpgeorge]

@WebReflection please take a look at this PR and see what you think. It's a bit different to what we discussed on Discord, the difference being that undefined is not converted to Py None, but rather to a distinct object js.undefined. That means that JS functions that return their default value of undefined will pass that value through to Python. But, that has very little impact (no tests we have are impacted by that), and doing it this way keeps a proper separation between undefined and null on both sides (Py and JS sides). So IMO it feels nice and consistent, a one-to-one correspondence between null and None.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.39%. Comparing base (c10a74b) to head (cfd5a8e).

Additional details and impacted files

@@           Coverage Diff           @@
##           master   #14483   +/-   ##
=======================================
  Coverage   98.39%   98.39%           
=======================================
  Files         161      161           
  Lines       21204    21204           
=======================================
  Hits        20864    20864           
  Misses        340      340           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[WebReflection]

that not as method kinda bothers me ... function some({ thing = () => {} } = {}) {} is a valid JS expectation, if this is covered in here I am OK with that comment (if explained somewhere else), otherwise I wonder "why"

[dpgeorge]

I think it's just that the comment I wrote here is confusing. I meant that here the code is looking up the attribute as a key within the dict (or ordereddict). That's opposed to the standard case of looking up the attribute as the name of a member/function/method of the target object.

Eg looking up attr on target will have the following logic:

• If target is a dict or ordereddict instance then lookup target[attr], and return the result. If the lookup failed, return js.undefined.
• Otherwise, lookup target.foo, raising an exception if it can't be found.

I've updated the comments to try and make it clearer.

I also added a test for passing through a function in the dict.

[WebReflection]

Awesome, 👍 for me!

[WebReflection]

it's true that methods (or utilities?) are rare, but not that much neither for JS related APIs ... I've left a comment that, once resolved or explained, would make me virtually approve this PR as I think it's awesome in both intent and expectations 👍