Brython - Python in the browser

[Pierre Quentel]

Le jeudi 20 décembre 2012 01:07:15 UTC+1, Terry Reedy a écrit :
> On 12/19/2012 1:19 PM, Pierre Quentel wrote:
> 
> 
> 
> > The objective of Brython is to replace Javascript by Python as the
> 
> > scripting language for web browsers, making it usable on all
> 
> > terminals including smartphones, tablets, connected TVs, etc. Please
> 
> > forgive the lack of ambition ;-)
> 
> 
> 
> This sounds similar to pyjs, but the latter has two big problems: a) 
> 
> personality conflicts splits among the developers; b) last I knew, it 
> 
> was stuck on Python 2.
> 
It is indeed different from pyjs : both translate Python into Javascript, but with Brython the translation is done on the fly by the browser, with pyjs is is done once by a Python script
> 
> 
> I think your home page/doc/announcement should specify Python 3 at the 
> 
> top, so it is not a mystery until one reads down to
> 
> "Brython supports most keywords and functions of Python 3 : "
> 
Done on the home page
> 
> 
> "lists are created with [] or list(), tuples with () or tuple(), 
> 
> dictionaries with {} or dict() and sets with set()"
> 
> 
> 
> non-empty sets are also created with {} and you should support that.
> 
Ok, I put this point in the issue tracker
> 
> 
> > The best introduction is to visit the Brython site
> 
> > (http://www.brython.info).
> 
> 
> 
> That says that my browser, Firefox 17, does not support HTML5. Golly 
> 
> gee. I don't think any browser support5 all of that moving target, and 
> 
> Gecko apparently supports about as large a subset as most.
> 
> https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
> 
> It is possible the FF still does not support the particular feature 
> 
> needed for the clock, but then the page should say just that. Has the 
> 
> latest FF (17) actually been tested?
> 
I changed the error message adding "or Javascript is turned off"
> 
> 
> > To create an element, for instance an HTML anchor :
> 
> > doc <= A('Python',href="http://www.python.org")
> 
> 
> 
> To me, that is a awful choice and I urge you to change it.
> 
> 
> 
> '<=' is not just an operator, it is a comparison operator. It normally 
> 
> return False or True. Numpy array comparison returns arrays of booleans, 
> 
> so the meaning is extended, not completely changed. People will often be 
> 
> using it with its normal mean in conditionals elsewhere, so this usage 
> 
> creates strong cognitive dissonance. Also, using an expression as a 
> 
> statement is allowed, but except in the interactive interpreter, it only 
> 
> makes sense with an expression that obviously has side-effects or could 
> 
> have side-effects (like the expression 'mylist.sort()'. It just looks 
> 
> wrong to an experienced Python programmer like me.
> 
> 
> 
> It also is unnecessary. Use '+=' or '|='. The former means just what you 
> 
> want the statement to do and the latter is at least somewhat related 
> 
> (bit or-addition) and is rarely used and is very unlikely to be used in 
> 
> code intended for a browser.
> 
> 
I'm afraid I am going to disagree. The document is a tree structure, and today Python doesn't have a syntax for easily manipulating trees. To add a child to a node, using an operator instead of a function call saves a lot of typing ; <= looks like a left arrow, which is a visual indication of the meaning "receive as child". |= doesn't have this arrow shape

+= is supported by Brython, but it means something different. <= means "add child" ; the addition operator + means "add brother"

For instance,

d = UL(LI('test1'))
d += UL(LI('test2'))
doc <= d

will show two unordered lists at the same level, while
        
d = UL(LI('test1'))
d <= UL(LI('test2'))
doc <= d

will nest the second list inside the first one

In fact, even in CPython there could be a built-in tree class that could be managed by a syntax such as this one
> 
> 
> 
> > It still lacks important features of Python, mostly list
> 
> > comprehensions and classes ;
> 
> 
> 
> Since Python 3 has 4 types of comprehensions, while Python 2 only has 
> 
> list comprehensions, I took this to mean that Brython was Python 2.
> 
> 
> 
> And yes, I am all in favor of being able to use a subset of Py3 instead 
> 
> of javascript. A full Python interpreter in a browser is too dangerous. 
> 
> (Actually, I think javascript is too, but that is a different issue.) 
> 
> Python translated to javascript cannot be worse than javascript. I 
> 
> presume the same would be true if the javascript step were omitted and 
> 
> Python were directly compiled to the virtual machines defined by current 
> 
> javascript engines.
> 
> 
> 
> -- 
> 
> Terry Jan Reedy