@ntoll there are 2 regressions (or one regression and one changed behavior) in MicroPython:

• string.translate does not exist anymore
• if js_proxy_ref: print("ok") never passes the if check, even if the js_proxy_ref is, in fact, a js_proxy_ref ... this might be desired because it's a sloppy check anyway, but it could also break existing code in the wild

I already informed @dpgeorge about both, let's see if we can have at least string.translate back otherwise I don't feel like we can release latest MicroPython as it is.

@WebReflection ack on that. Let's hold until @dpgeorge gets back to us about both issues. 👍

Both of those things are bugs, and now fixed by the new release here: https://www.npmjs.com/package/@micropython/micropython-webassembly-pyscript/v/1.28.0-preview-233

• if js_proxy_ref: print("ok") never passes the if check, even if the js_proxy_ref is, in fact, a js_proxy_ref ... this might be desired because it's a sloppy check anyway

That was failing because js_proxy_ref was referencing a JS object that had a .length attribute which returned 0. And in the Python world, anything with zero length is considered False.

I'm not sure how Pyodide handles that particular case. What if js_proxy_ref was an empty JS array, how would you expect bool(js_proxy_ref) to behave there?

Well, we can have that discussion another time. For now, it should be back to the old behaviour, where all JsProxy objects are considered true.

@dpgeorge

That was failing because js_proxy_ref was referencing a JS object that had a .length attribute which returned 0. And in the Python world, anything with zero length is considered False.

It is also very possible the test case in point was plain wrong ... the surprise was a change of behavior but the detail is that I was never asking the length of that object, I was trying to retrieve the ability to iterate via Symbol.iterator which could be used by (badly written) 3rd parties ... that test is there because we had some 3rd party library failing with Python objects due ref[Symbol.iterator] truthy check, but it's also true that such check was happening in the JS world, not in the Python one ...

how would you expect bool(js_proxy_ref) to behave there?

it's one of those weird PL translations:

• in JS, anything that is not falsy should be considered truthy
• in Python, anything that is not expected to be truthy, should remain falsy

That means, in Python if js_array_ref: ... should not move on if the length of that array is 0 but in JS that should always return true even if the length is zero.

On the other side, if the reference is iterable, it should never return falsy values out of if any_ref[Symbol.iterable]: ... ... let it throw in Python objects, let it return truthy (or a wrap) otherwise?

Again, I've changed already the test in case because it was weird anyway, tested from a Python world, still I think it's important that these semantics are preserved per each PL world/semantic meaning.

@ntoll and @dpgeorge , that being said, I've already updated all the things and CI is happy now, I think we should consider publishing PyScript with latest MicroPython as it is and see what people think, discover, or create with all the latest great features that such preview version brought to the Web plate ... agreed?

this has been published on npm as:

• JS https://cdn.jsdelivr.net/npm/@pyscript/[email protected]/dist/core.js
• CSS https://cdn.jsdelivr.net/npm/@pyscript/[email protected]/dist/core.css

That means, in Python if js_array_ref: ... should not move on if the length of that array is 0

Maybe we need to add a special case for this, because currently bool(empyt_js_array) is True on the Py side.