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 -- http://mail.python.org/mailman/listinfo/python-list