null/undefined/None comparisons, and None Bry=>JS conversion.

[denis-migdal]

Hi,

In JS we have :

null == undefined // true
null === undefined // false

It means that null and undefined are the same values, but are "different". In Python, I assume that is is more or less equivalent to === :

The == operator compares the value or equality of two objects, whereas the Python is operator checks whether two variables point to the same object in memory. In the vast majority of cases, this means you should use the equality operators == and != , except when you're comparing to None .

If we compare None to anything, it will always return False in Python, except while comparing it to None itself.

Therefore I think that in Brython we should have :

null == undefined // True <- currently is False
null  is undefined // False

We could also assume that None has the same value as null and undefined, but is different. This would help solving the following issues :

JS functions returns undefined, while Python function returns None, which might cause issues :

x = non_returning_function();
if x is None or x is undefined:  // we can't know whether x is undefined or None, which could lead to some unexpected consequences.
      pass

instead we could have :

x = non_returning_function(); // we can't know if x is undefined or None.
if x == None: # we "hide" the JavaScript complexity
      print('undefined or null or None')
if x is None:   # If we really want to ensure the return value.
     print('ensuring we do have None')

The same, when accessing to some JS values, have null == None could be expected, and would be coherent as undefined == null.

I do not think such behavior should produce unexpected side effect as :

• is usage is advise in Python when using None. So every existing comparisons should be using None, and thus having strong insurance about the real value.
• == could be used specifically in Brython, to help not being too bothered by undefined and null in trivial cases.

For conversions between Brython <=> Javascript :

• Javascript => Brython : do not convert.
• Javascript <= Brython : do not convert, but, by default, print a console.warn() with a python trace.

/!\ None value given to JavaScript function. Convert it to undefined or null before giving it. To disable this error option... to raise exception instead option .... [THE STACK]

Indeed, giving a None to Javascript could be dangerous, e.g. if it expects undefined for a callback return value.

// imagine a JS library exposing the following function :
function doStuff(callback) {

       if( callback() ) { // if null/undefined => false, BUT if None => true !
             // do stuff
       }
}

Hence the need to warn the user. The behavior could be controlled through an option given to Brython (e.g. NONE_CONVERSION) :

• default : prints the warning.
• silent : do not print the warning, should not be used, but maybe some users might want that ?
• strict : raise an exception, could be useful in development for some people.

Cordially,

[denis-migdal]

One way to fix the function return type in Brython => JS callbacks, is to build functions in a way that implicit or empty return, returns an *internal()** temporary special value : e.g. <ImplReturn>.

(*) This means that Brython users will never see or access this value. It'll be just used internally to track implicit returns.

Then :

• when called in Brython, if the function return value is <ImplReturn>, replace it by None.
• when called in JS (so inside a function wrapper), if the returned value is <ImplReturn> replace it by undefined.

Then, we could have None being implemented as null*, which would remove the need to warn the user when trying to give None to JS.

(*) It was almost the case before, but couldn't due to non-returning function having their return values converted to null.

This could be implemented in several ways :

• (a) checking the return value inside the function wrapper (JS) and replace the bind() by an anonymous function checking the return type (Brython). BUT this costs a comparison at each return value.
• (b) an added parameter to the function those value will be returned upon implicit or empty return. Then, the JS function wrapper will give undefined (JS) and the anonymous function replacing bind() would give None. BUT this costs an extra-parameter at each call. Should be more performant compared to previous solution.
• (c) having all Brython functions having a property xxx.ImplRetVal being equal to None. When being called, put this value inside a local variable ImplRetVal and put the property xxx.ImplRetVal back to None (could be removed by transpiler if no explicit return or empty return are detecting inside the function). Then upon implicit or empty return, returns this value. Then, in JS wrapper, when calling the function, setting its ImplRetVal to undefined before calling the wrapped brython function. This should be more performant than the 2 previous solutions with little to no overcost in Brython BUT would not support functions returning another function return value.. But that should cover 99% of cases. If you do return foo(), you should expect a value, therefore None/null.

I think solution (c) might be a good solution. The browser should be able to optimize the local variable, hence the only cost is accessing to the stored return value. I'd argue that the cost of it should be very little compared to the frame and parameters management made at each function calls.

[PierreQuentel]

In the commit referenced above I have implemented javascript.NULL == javascript.UNDEFINED (Javascript is an endless source of surprises...)

I agree that there should be no "magic" conversion between None, null and undefined. I have no clear opinion at the moment if we should warn when None is passed to JS - perhaps mark it as deprecated ? But can we exclude use cases when we really want to pass None to a JS function ?

For the rest of your comments, there is something I don't get: you seem to assume that the developer doesn't know whether non_returning_function is a Brython function or a Javascript function. I think in the contrary that he actually knows where the function comes from, and

• if it is a Javascript function, the test is if(result === undefined) in Javascript and if result is UNDEFINED in Brython.
• if it is a Brython function, the test is if result is None in Brython and if(result === __BRYTHON__.builtins.None) in Javascript.

Am I missing something ?

[denis-migdal]

In the commit referenced above I have implemented javascript.NULL == javascript.UNDEFINED (Javascript is an endless source of surprises...)

Yeah, JS is a very dirty language.

Wait until you see that {}+[] is 0 but []+{} is an object xD.

In JS, == is when object has the same value after conversions/castings, meaning, that e.g. "" == false is true. When === is for a more strict comparaison, without conversions/castings, e.g. "" === false is false.

For values (sémantiques de valeurs), === is true when they have the same value, while for objects (sémantiques d'entités) it is true when they are the same reference.

For the rest of your comments, there is something I don't get: you seem to assume that the developer doesn't know whether non_returning_function is a Brython function or a Javascript function. I think in the contrary that he actually knows where the function comes from

When you work with callbacks, you can't be sure of the origin of the callback, or controls what the called function will do with the callback.

For exemple, if we use a JS function (e.g. in a library) and give him a callback :

function foo( callback ) {

       if( callback() ) {
             console.log('returned true');       
       }
}

def callback()
     pass

If the callback returns None, the condition will be evaluated to true, when it should be evaluated to false for a non-returning function.

Proposition A.

As null and undefined doesn't exists in Python, why not "hiding" their existence to Brython users ?

• null and undefined doesn't exists in Brython, for Brython users, it only exists internally.
• None symbol would be internally represented as null
• Implicit or empty returning would internally returns undefined
• In JS <=> Brython, values are exchanged without conversions.
• <null> and <undefined> would exactly behave like None.
  • Access to the null and undefined symbols is"hidden" to Brython users.
  • <null> == <undefined> and <null> is <undefined> would both be true, because they'd both be None for Brython users. Meaning it'll be used as <value that is null or undefined> is None equals true.

Meaning that return None internally returns null and return internally returns undefined.

Then for more control, only and only when wanting more control with JS/Brython interactions we could provide :

• javascript.isNoneNull(<null or undefined>) and javascript.isNoneUndefined(<null or undefined>), that'd be the only way (at the exception of console.log()) to know whether the object is internally null or undefined. Used to process data comming from JS (and only for that).
• javascript.NoneNull and javascript.NoneUndefined to be able to explicitly get an internal null or undefined value before giving them to JS (and only for that).

But this shouldn't be used by Brython users except in the very specific cases of interacting with JS : in python, there is no null or undefined, only None. So Brython users, except when wanting explicit interactions with JS shouldn't even know they are 2 things. As <null> is <undefined> in Brython, javascript.NoneNull is javascript.NoneUndefined would also be true (because they are <null> and <undefined>.

The naming enables to insist that they are None.

Proposition B.

Keep 3 internal values :

• undefined
• null
• None (like an "undecided" between undefined and null).

BUT

• null and undefined doesn't exists in Brython, for Brython users, it only exists internally.
• None symbol is internally None
  • implicit and empty return could be internally undefined (or could be also None).
• null is undefined, null is None, undefined is None : they are the same thing as they don't exists in Brython.
• <null> and <undefined> would exactly behave like None.
  • Access to the null and undefined symbols is"hidden" to Brython users.
• null and undefined can be exchanged between JS and Brython without needing conversions.
• None value raises an exception when given to JS : you have to first convert it either to internal null or undefined.
• only and only when wanting more control with JS/Brython interactions we could provide :
  • javascript.enforceNoneNull(val) or javascript.enforceNoneUndefined(val) : returns null or undefined. Like a kind of "conversion" before giving it to JS.
  • javascript.checkIfNoneNull(val) and javascript.checkIfNoneUndefined(val) : when processing the result of a JS function.

The naming enables to insist that they are None.