Re: Brython (Python in the browser)
Awesome.. Wonderful work! -- https://mail.python.org/mailman/listinfo/python-list
Re: Brython (Python in the browser)
Le vendredi 27 décembre 2013 17:12:09 UTC+1, Johannes Schneider a écrit : > On 27.12.2013 07:14, Pierre Quentel wrote: > > > Hi, > > > > > > Ever wanted to use Python instead of Javascript for web client programming > > ? Take a look at Brython, an implementation of Python 3 in the browser, > > with an interface with DOM elements and events > > > > > > Its use is very simple : > > > - load the Javascript library brython.js :
Re: Brython (Python in the browser)
Le vendredi 27 décembre 2013 15:56:33 UTC+1, jonas.t...@gmail.com a écrit : > Den fredagen den 27:e december 2013 kl. 07:14:35 UTC+1 skrev Pierre Quentel: > > > Hi, > > > > > > > > > > > > Ever wanted to use Python instead of Javascript for web client programming > > ? Take a look at Brython, an implementation of Python 3 in the browser, > > with an interface with DOM elements and events > > > > > > > > > > > > Its use is very simple : > > > > > > - load the Javascript library brython.js :
Re: Brython (Python in the browser)
On 27.12.2013 07:14, Pierre Quentel wrote: Hi, Ever wanted to use Python instead of Javascript for web client programming ? Take a look at Brython, an implementation of Python 3 in the browser, with an interface with DOM elements and events Its use is very simple : - load the Javascript library brython.js :
Re: Brython (Python in the browser)
Den fredagen den 27:e december 2013 kl. 07:14:35 UTC+1 skrev Pierre Quentel: > Hi, > > > > Ever wanted to use Python instead of Javascript for web client programming ? > Take a look at Brython, an implementation of Python 3 in the browser, with an > interface with DOM elements and events > > > > Its use is very simple : > > - load the Javascript library brython.js :
Re: Brython (Python in the browser)
In article <234a1a8d-e491-4eec-8bd5-7931cf4f7...@googlegroups.com>, Pierre Quentel wrote: > Hi, > > Ever wanted to use Python instead of Javascript for web client programming ? > Take a look at Brython, an implementation of Python 3 in the browser, with an > interface with DOM elements and events > > Its use is very simple : > - load the Javascript library brython.js :
Brython (Python in the browser)
Hi, Ever wanted to use Python instead of Javascript for web client programming ? Take a look at Brython, an implementation of Python 3 in the browser, with an interface with DOM elements and events Its use is very simple : - load the Javascript library brython.js :
Re: Brython - Python in the browser
On Sun, Dec 23, 2012 at 7:31 AM, Dan Sommers wrote: > On Sat, 22 Dec 2012 23:11:00 +1100, Chris Angelico wrote: > >> "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] >> and "This is a string" // 3 ==> ["This ", "is a ", "strin"] >> then "This is a string" % 3 ==> ["g"] or possibly "g" >> >> which is incompatible with current usage. But that's a meaning that >> makes reasonable sense as "modulo". > > So why are we all so comfortable with using "*" as the operator for > multiplication? I'm sure that a new programming language that dared to > use U+00D7 or U+2715 for multiplication would be instantly rejected on > the grounds that it was confusing and incompatible with current practice. Less on the confusing and more on the hard to type; same reason we don't indicate division by writing a long bar, but use the slash instead. Also, algebra has a tendency toward short variable names, where programming tends toward longer ones, so algebra optimizes in favour of multiplication - that's why we don't write code like "h{ello}w{orld}" to mean "multiply hello by world". > Until recently, the number of characters available to a programming > language was limited (APL notwithstanding). REXX had two boolean negation operators, one of which wasn't ASCII. > Practicality beat (paste tense) purity. Yep. Definitely. We need to be able to type code fast, read code fast, and worry about algebra slowly. Arguments from algebra are mainly for justifying a new piece of syntax so people can understand it without having to keep the manual open beside them. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 1:31 PM, Dan Sommers wrote: > So why are we all so comfortable with using "*" as the operator for > multiplication? I'm sure that a new programming language that dared to > use U+00D7 or U+2715 for multiplication would be instantly rejected on > the grounds that it was confusing and incompatible with current practice. As long as the language doesn't also use "*" for anything so that I can just alias Shift-8 in my editor, no objections here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, 22 Dec 2012 23:11:00 +1100, Chris Angelico wrote: > "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] > and "This is a string" // 3 ==> ["This ", "is a ", "strin"] > then "This is a string" % 3 ==> ["g"] or possibly "g" > > which is incompatible with current usage. But that's a meaning that > makes reasonable sense as "modulo". So why are we all so comfortable with using "*" as the operator for multiplication? I'm sure that a new programming language that dared to use U+00D7 or U+2715 for multiplication would be instantly rejected on the grounds that it was confusing and incompatible with current practice. Wikipedia (http://en.wikipedia.org/wiki/Asterisk) doesn't even list multiplication as a mathematical use of the asterisk. Until recently, the number of characters available to a programming language was limited (APL notwithstanding). Practicality beat (paste tense) purity. Dan -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 10:05 PM, Steven D'Aprano wrote: > On Sat, 22 Dec 2012 20:08:25 +1100, Chris Angelico wrote: > >> I don't see "string % tuple" as a good syntax; I prefer to spell it >> sprintf("format",arg,arg,arg). > > Very possibly one of the worst names ever from a language that excels at > bad names. "Sprint f"? WTF? > > Certainly not appropriate for Python, where a sprintf equivalent would > return a new string, rather than automatically print the result. Oh > wait... C's sprintf doesn't automatically print either. > > *wink* Sure, it's not ideal, but it's the string-returning form of printf, which prints formatted text, so it's not completely inappropriate. But my point stands: it's an easy thing to search for. >> When it >> comes to operators on strings, what I'd prefer to see is something that >> does more-or-less what the operator does with integers - for instance: >> >> "This is a string" / " " ==> ["This","is","a","string"] > > I don't see the connection between the above and numeric division. If it > were this: > > "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] > > (and presumably // 3 would be the same except the "g" would be dropped) > then I could see the connection. But there's no relationship between > numeric division, which divides a number up into N equal-sized parts, and > string splitting as you show above. Sure, but it's still dividing. It's a different form of division, but it still makes sense. "Oh, you're dividing that string by a delimiter. I'd prefer to call it 'on' a delimiter, but 'by' works." Your description makes perfectly good sense too, though; however, if: "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] and "This is a string" // 3 ==> ["This ", "is a ", "strin"] then "This is a string" % 3 ==> ["g"] or possibly "g" which is incompatible with current usage. But that's a meaning that makes reasonable sense as "modulo". >> Taking a string modulo a tuple doesn't make any sense in itself, > > Taking an integer cross an integer doesn't make any sense if you haven't > learned the meaning of the + operator. Why insist that only string > operators must make inherent sense to somebody who doesn't know what the > operator means? If we're allowed to learn the meaning of + * and &, why > not % as well? Sure, but + and * have meaning in mathematics, not just programming, and it's a similar meaning. Even the much-maligned = assignment, which has quite a different meaning to = equality, which itself isn't the same as the = equality in mathematics, is sufficiently close that it's grokkable. But someone coming from a mathematical background has no particular advantage in figuring out that % means formatting, or that <= means add child. That doesn't mean they shouldn't be done, just that the justification hump is that bit higher. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, 22 Dec 2012 20:08:25 +1100, Chris Angelico wrote: > I don't see "string % tuple" as a good syntax; I prefer to spell it > sprintf("format",arg,arg,arg). Very possibly one of the worst names ever from a language that excels at bad names. "Sprint f"? WTF? Certainly not appropriate for Python, where a sprintf equivalent would return a new string, rather than automatically print the result. Oh wait... C's sprintf doesn't automatically print either. *wink* > When it > comes to operators on strings, what I'd prefer to see is something that > does more-or-less what the operator does with integers - for instance: > > "This is a string" / " " ==> ["This","is","a","string"] I don't see the connection between the above and numeric division. If it were this: "This is a string" / 3 ==> ["This ", "is a ", "strin", "g"] (and presumably // 3 would be the same except the "g" would be dropped) then I could see the connection. But there's no relationship between numeric division, which divides a number up into N equal-sized parts, and string splitting as you show above. Of course, if we can just invent a meaning for the % operator that has nothing to do with either percentages or numeric modulo, then we could equally invent a meaning for / for strings. But if we did so, it still wouldn't have anything to do with numeric division. > Taking a string modulo a tuple doesn't make any sense in itself, Taking an integer cross an integer doesn't make any sense if you haven't learned the meaning of the + operator. Why insist that only string operators must make inherent sense to somebody who doesn't know what the operator means? If we're allowed to learn the meaning of + * and &, why not % as well? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 7:54 PM, Pierre Quentel wrote: >> Still, it tends to be a lot harder to explain, document, and read >> documentation for, something that uses operators weirdly, rather than >> keyword-searchable method names. > > You don't explain how to use the Python syntax (for instance the operator %, > which behaves very differently between integers and strings) by explaining > what happens in the underlying C code in the different cases, do you ? Agreed, and it's sometimes confusing. I don't see "string % tuple" as a good syntax; I prefer to spell it sprintf("format",arg,arg,arg). When it comes to operators on strings, what I'd prefer to see is something that does more-or-less what the operator does with integers - for instance: "This is a string" / " " ==> ["This","is","a","string"] Taking a string modulo a tuple doesn't make any sense in itself, so it CAN be given an alternative meaning. But if you see that in a program and aren't sufficiently familiar with %s formatting to recognize it, how are you going to locate the documentation on the subject? Googling for 'python % string' doesn't help; 'python string modulo' brings up an article on informit.com that explains the matter, but nothing official. By contrast, searching for 'c sprintf' brings up heaps of useful links, because 'sprintf' is a searchable keyword. On the flip side, operator-based notations end up a lot more compact. I'd definitely not want to give up, for instance, list comprehension syntax. Difficulty of searching for docs is a downside, but definitely not a blocker. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
I forgot to mention : list comprehensions and the ternary operator (r1 if cond else r2) are now supported ! - Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> Still, it tends to be a lot harder to explain, document, and read > documentation for, something that uses operators weirdly, rather than > keyword-searchable method names. You don't explain how to use the Python syntax (for instance the operator %, which behaves very differently between integers and strings) by explaining what happens in the underlying C code in the different cases, do you ? I would put the above explanations in the "implementation notes" of Brython, but not on the "how to use Brython" documentation, which is quite simple to explain with <= and + (it's in the section "Handling of HTML documents" in the docs) -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 6:57 PM, Pierre Quentel wrote: > I was over-simplifying - or, to put is less diplomatically, I screwed up - > when I answered that the addition returned a string. As Chris pointed out, it > made the explanation very confusing. My apologies > > The objects handled by + and <= can be : > - strings, integers, floats > - instances of $TagClass instances (more precisely, of classes copied from > $TagClass, one for each HTML tag) : they are wrappers around a DOM element. > The DOM element itself is the attribute "elt" of the $TagClass instance > - the document, represented by the keyword doc. Its attribute "elt" is the > document (top of the DOM tree) > - instances of $AbstractClass, a container with a list of DOM elements. This > list is the attribute "children" of the $TagClass instance Ah! Okay, that makes a LOT more sense. Still, it tends to be a lot harder to explain, document, and read documentation for, something that uses operators weirdly, rather than keyword-searchable method names. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
I was over-simplifying - or, to put is less diplomatically, I screwed up - when I answered that the addition returned a string. As Chris pointed out, it made the explanation very confusing. My apologies The objects handled by + and <= can be : - strings, integers, floats - instances of $TagClass instances (more precisely, of classes copied from $TagClass, one for each HTML tag) : they are wrappers around a DOM element. The DOM element itself is the attribute "elt" of the $TagClass instance - the document, represented by the keyword doc. Its attribute "elt" is the document (top of the DOM tree) - instances of $AbstractClass, a container with a list of DOM elements. This list is the attribute "children" of the $TagClass instance Depending of the objects types, a+b returns the following objects : string + string : string (!) string + $TagClass : $AbstractTag with children [textNode(a),b.elt] string + $AbstractTag : $AbstractTag with [textNode(b)]+ b.children The 2 latter are implemented by the method __radd__ of $TagClass and $AbstractTag, invoqued by the method __add__ of the string class $TagClass + string : $AbstractTag with [a.elt,textNode(b)] $TagClass + $TagClass : $AbstractTag with [a.elt,b.elt] $TagClass + $AbstractTag : $AbstractTag with [a.elt]+b.children $AbstractTag + string : $AbstractTag with a.children+[textNode(b)] $AbstractTag + $TagClass : $AbstractTag with a.children + [b.elt] $AbstractTag + $AbstractTag : $AbstractTag with a.children + b.children (any type) + doc : unsupported doc + (any type) : unsupported The operation x <= y does the following : string <= (any object) : comparison, if possible ($TagClass | doc) <= string | integer | float : adds textNode(str(y)) to x.elt ($TagClass | doc) <= $TagClass : adds child y.elt to parent x.elt ($TagClass | doc) <= $AbstractTag : adds DOM elements in y.children to x.elt $AbstractClass <= (any type) : unsupported - Pierre -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> Oh, and repr is just a synonym of str, which makes it useless. 3 days ago repr was not even implemented at all, so it's a step forward... -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, 21 Dec 2012 12:25:01 +0100, Stefan Behnel wrote: > If that's your intention, then instead of coming up with something > totally new, unpythonic and ugly, why not take the normal Python route > and implement a subset of the ElementTree API? Yo mean something old, unpythonic and ugly? :-P -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 10:50 AM, Amirouche Boubekki wrote: > Last time I checked DOM > manipulation is not the primary way for js devs to do DOM manipulation > anymore, or is it ? Javascript template engines do DOM manipulation but this > is almost invisible for the user... Not sure how most of the world works, but I write using the DOM. There's little point using jquery etc when what you're doing is really simple - which, for me, it is. So I'm probably not representative. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 10:57 AM, Ian Kelly wrote: > From the code, it appears that adding two nodes together *actually* > returns a $AbstractTag object, which seems to be just a container for > a list of child nodes with no parent, that automagically gets removed > from the hierarchy when appended to another node. That actually makes good sense. The sum of two nodes is an ordered pair of peers, which will be added sequentially to the same parent. For this to work, *every* situation needs to be able to handle (with equal ease) a string, an $AbstractTag, or a node. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 4:45 PM, Ian Kelly wrote: > In my playing around with it just now, the addition doesn't seem to > actually return a string. >From the code, it appears that adding two nodes together *actually* returns a $AbstractTag object, which seems to be just a container for a list of child nodes with no parent, that automagically gets removed from the hierarchy when appended to another node. -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 4:45 PM, Ian Kelly wrote: > In Brython, the str builtin does not return strings? Oh, and repr is just a synonym of str, which makes it useless. -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Héllo, > > doc <= 'blah blah x I will surely backlog latter or some crytologist from the futur will do and he will surely agree about the fact something strange happened around december 2012. Sorry for that, that's me trying to be funny. Last time I checked DOM manipulation is not the primary way for js devs to do DOM manipulation anymore, or is it ? Javascript template engines do DOM manipulation but this is almost invisible for the user so whatever the API, I expect this will be minor, if not completly overlooked by users of Brython. I could even argue more that for cross-language knowledge sharing the low level API should be the same but no. Brython is a very good idea. I failed at something similar except I took the pyjs route and focused on classes (functions being callable class objects) and "bindings" which is IMO more interessant than list comprehensions, operator-overloading and plain functions. The idea was that bindings will be even more important than in CPython because most of the hard work for browser compatibility was already done and optimised by the JS community. I may completly be off beat but the vision was that Python would be for framework and application developpement and not for utility libraries that would replace jQuery, SocketIO, Mediator.js History.js or any template engine hence the focus on classes and meta-programming. What is the plan regarding this issues in Brython ? Regards, Amirouche -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 3:52 PM, Chris Angelico wrote: > On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel > wrote: >> >>> Hmm. So when that gets added into a DIV, it has to get parsed for >>> tags? How does this work? This seems very odd. I would have expected >>> it to remain as DOM objects. >> >> In DIV(child) : >> - if child is a string, integer or float, a text node is added (addChild) to >> the DIV element, with the string value of child >> - if child is another DOM element (as in DIV(B('foo'))) then this element is >> added to the DIV element > > Meaning that: > doc <= ' > will add literal text, not a paragraph object, right? That's > definitely what I would expect. > >> doc <= 'blah blah x> >> It will add a text node to the document, with the string 'blah blah x> followed by 'True!' in bold characters > > This is where it's getting confusing. My expectation of this is that > it adds a text node with the literal text, followed by a bold node > with its child text. This operation should never involve the parsing > of HTML tags, as the document structure is all there in the code. So > it ought to be a DOM object, not a text string, that gets <='d onto > doc (is <= a verb now?). That means the result of the addition has to > be a DOM object, not a text string; but you said that adding a string > to a B object converts the object to a string and concatenates the > strings. > > Do you see now what I mean about the API being difficult to explain? In my playing around with it just now, the addition doesn't seem to actually return a string. I typed this script into the test console: log('hello ' + B('world')) and clicked Run, and the result was: [object Object] whereas if I just try to log a plain string literal, it actually prints out the string. Somewhat disturbingly, this also gives the [object Object] result: log(str('hello ' + B('world'))) In Brython, the str builtin does not return strings? -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel wrote: > >> Hmm. So when that gets added into a DIV, it has to get parsed for >> tags? How does this work? This seems very odd. I would have expected >> it to remain as DOM objects. > > In DIV(child) : > - if child is a string, integer or float, a text node is added (addChild) to > the DIV element, with the string value of child > - if child is another DOM element (as in DIV(B('foo'))) then this element is > added to the DIV element Meaning that: doc <= ' will add literal text, not a paragraph object, right? That's definitely what I would expect. > doc <= 'blah blah x > It will add a text node to the document, with the string 'blah blah x followed by 'True!' in bold characters This is where it's getting confusing. My expectation of this is that it adds a text node with the literal text, followed by a bold node with its child text. This operation should never involve the parsing of HTML tags, as the document structure is all there in the code. So it ought to be a DOM object, not a text string, that gets <='d onto doc (is <= a verb now?). That means the result of the addition has to be a DOM object, not a text string; but you said that adding a string to a B object converts the object to a string and concatenates the strings. Do you see now what I mean about the API being difficult to explain? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 1:59 PM, Pierre Quentel wrote: >> By the way, what is Brython actually doing when you append a child to >> the document itself like that? Usually I would expect a div to be >> appended to the body or to another div. The above looks like it would >> attach the new div as a sibling of the html element. Or is it just >> calling document.write()? > > dom_elt <= obj actually adds one or several DOM nodes (it depends of the > class of obj) to the DOM node represented by dom_elt. It's difficult to > explain all the cases here, you would have to take a look at the code in > py_dom.js, but <= and + work on the DOM tree, there is no document.write > anywhere Thanks, I found my answer in the source: doc <= element basically calls document.body.appendChild(element) -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> The interpreter, though, will be more than happy to treat that as a > comparison if the LHS is not the type that you think it is. For > example, maybe you've added it to a string at some point, and now it's > a string instead of an element. I guess that since doc is made a > keyword, that probably couldn't happen in this example, but it could > happen when trying to add child nodes to other nodes. Unsurprisingly, the translation engine in Brython transforms x <= y into x.__le__(y) If x is a string, then __le__ means of course "lesser or equal" so y can only be a string, otherwise an exception is raised ; this is similar to trying to add a child node to a text node in the DOM > By the way, what is Brython actually doing when you append a child to > the document itself like that? Usually I would expect a div to be > appended to the body or to another div. The above looks like it would > attach the new div as a sibling of the html element. Or is it just > calling document.write()? dom_elt <= obj actually adds one or several DOM nodes (it depends of the class of obj) to the DOM node represented by dom_elt. It's difficult to explain all the cases here, you would have to take a look at the code in py_dom.js, but <= and + work on the DOM tree, there is no document.write anywhere -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 9:16 AM, Pierre Quentel wrote: >> <= is a comparison expression operator, which is completely different. >> It is just wrong for this usage. I am 99.9% sure you will come to regret >> it eventually. Better to make the change now than in Brython2 or Brython3. > > I am 99.99% sure of the contrary, having used this syntax for more than 3 > years now, as the users of the Karrigell framework with the HTMLTags module > > Another point why there is no possible confusion is that when <= is a > comparison operator, it is never used in an standalone expression like "a <= > b", with the left term of the comparison starting the line ; it is always > used in an expression like "if x <= 10", "while x <= 5", "assert x <= 0", > "return foo <= bar" etc. > > So when you see a line like > > doc <= DIV('hello') > > it should be obvious that you are not *comparing* doc and DIV('hello'), > because if it was the case, the line would do nothing The interpreter, though, will be more than happy to treat that as a comparison if the LHS is not the type that you think it is. For example, maybe you've added it to a string at some point, and now it's a string instead of an element. I guess that since doc is made a keyword, that probably couldn't happen in this example, but it could happen when trying to add child nodes to other nodes. By the way, what is Brython actually doing when you append a child to the document itself like that? Usually I would expect a div to be appended to the body or to another div. The above looks like it would attach the new div as a sibling of the html element. Or is it just calling document.write()? -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Pierre Quentel, 21.12.2012 17:16: > So when you see a line like > > doc <= DIV('hello') > > it should be obvious that you are not *comparing* doc and DIV('hello'), > because if it was the case, the line would do nothing Yep, that's one of the main concerns - it looks like useless code, which is totally different from what it does. So it basically uses magic side-effects as part of the design, which is never a good thing. Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> Hmm. So when that gets added into a DIV, it has to get parsed for > tags? How does this work? This seems very odd. I would have expected > it to remain as DOM objects. In DIV(child) : - if child is a string, integer or float, a text node is added (addChild) to the DIV element, with the string value of child - if child is another DOM element (as in DIV(B('foo'))) then this element is added to the DIV element The code is in module py_dom.js, class $TagClass > > What happens if I do, for instance: > 'blah blah x You can test this code in the console on the Brython site (http://brython.info/tests/console_fr.html) : doc <= 'blah blah xhttp://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> <= is a comparison expression operator, which is completely different. > It is just wrong for this usage. I am 99.9% sure you will come to regret > it eventually. Better to make the change now than in Brython2 or Brython3. I am 99.99% sure of the contrary, having used this syntax for more than 3 years now, as the users of the Karrigell framework with the HTMLTags module Another point why there is no possible confusion is that when <= is a comparison operator, it is never used in an standalone expression like "a <= b", with the left term of the comparison starting the line ; it is always used in an expression like "if x <= 10", "while x <= 5", "assert x <= 0", "return foo <= bar" etc. So when you see a line like doc <= DIV('hello') it should be obvious that you are not *comparing* doc and DIV('hello'), because if it was the case, the line would do nothing -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Sat, Dec 22, 2012 at 2:36 AM, Pierre Quentel wrote: >> doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world'))) >> > No, with this syntax, the result of Tag('B').add('world') is below 'hello' in > the tree structure, not at the same level (just below Tag('DIV')) as it > should be No; look at the expanded form for a more readable (but syntactically identical) version: doc.add( Tag('DIV') .add('hello ') .add(Tag('B').add('world')) ) 'world' is below Tag('B') - look at the parentheses - but Tag('DIV').add('hello ') returns the DIV, not the hello, so B and hello are peers. > In this case it's not a real problem, but it's obvious if you want to produce > onetwo : you would need 2 different 'add' > top = Tag('UL') > top.add(Tag('LI').add('one')) > top.add(Tag('LI').add('two')) > > With the syntax used in Brython : UL(LI('one')+LI('two')) They can be directly combined, because Tag.add(self,other) returns self, not other. > Yes : a+b returns the string a+str(b) > 'hello '+B('world') > 'hello world' Hmm. So when that gets added into a DIV, it has to get parsed for tags? How does this work? This seems very odd. I would have expected it to remain as DOM objects. What happens if I do, for instance: 'blah blah x'+s+'' rather than any sort of class. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> Pythonic also means: > If the implementation is hard to explain, it's a bad idea. > What, exactly, does the sum of a string and a bolded string produce? Can you > explain that easily and clearly? Yes : a+b returns the string a+str(b) It is exactly what you get in CPython with >>> class B: ... def __init__(self,value): ... self.value = value ... def __radd__(self,other): ... return '%s%s' %(other,self.value) ... >>> 'hello '+B('world') 'hello world' > The DOM structure is, undeniably, quite verbose. But you could go for > something with the same tree structure while a lot less wordy by > simply returning self from lots of methods, thus allowing method > chaining - something like this: > > https://github.com/Rosuav/Gypsum/blob/master/window.pike#L247 > Hang me if I understand what this code is supposed to do ;-) > > To produce the HTML code > > hello world > > you might use: > > doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world'))) > No, with this syntax, the result of Tag('B').add('world') is below 'hello' in the tree structure, not at the same level (just below Tag('DIV')) as it should be In this case it's not a real problem, but it's obvious if you want to produce onetwo : you would need 2 different 'add' top = Tag('UL') top.add(Tag('LI').add('one')) top.add(Tag('LI').add('two')) With the syntax used in Brython : UL(LI('one')+LI('two')) > > Reject the idea if you will, but do at least please consider it :) > I did in fact consider many options before proposing this one. I have done a lot of web programming, including a web framework, and I faced the problem of generating HTML code from Python. I started with a syntax with nested parenthesis and chained methods returning self, only ending in ugly, unreadable code. Once I started using <= for "add child" and "+" for "add brother" (I first proposed it in the Python Cookbook recipe #366000, the HTMLTags module) - and I've used it on fairly large projects - the result was a much cleaner code -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Duncan Booth, 21.12.2012 14:14: > Pierre Quentel wrote: >>> If that's your intention, then instead of coming up with something >>> totally new, unpythonic and ugly, why not take the normal Python >>> route and implement a subset of the ElementTree API? >> >> Because the tree implementation in ElementTree or other tree modules >> in Python require a lot of typing and parenthesis >> >> To produce the HTML code >> >> hello world >> >> these modules require writing something like >> >> div = Tag('DIV') >> div.appendChild(TextNode('hello ')) >> b = Tag('B') >> b.appendChild(TextNode('world')) >> div.appendChild(b) >> doc.appendChild(div) > > Or you can do something like this: > > >>> from lxml.html.builder import * > >>> snippet = DIV("Hello ", B("world")) > >>> etree.tostring(snippet) > 'Hello world' For which there even happens to be an ElementTree implementation available: http://svn.effbot.org/public/stuff/sandbox/elementlib/builder.py (It's not like I made this up ...) Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Pierre Quentel wrote: >> If that's your intention, then instead of coming up with something >> totally new, unpythonic and ugly, why not take the normal Python >> route and implement a subset of the ElementTree API? >> >> Stefan > Because the tree implementation in ElementTree or other tree modules > in Python require a lot of typing and parenthesis > > To produce the HTML code > >hello world > > these modules require writing something like > > div = Tag('DIV') > div.appendChild(TextNode('hello ')) > b = Tag('B') > b.appendChild(TextNode('world')) > div.appendChild(b) > doc.appendChild(div) Or you can do something like this: >>> from lxml.html.builder import * >>> snippet = DIV("Hello ", B("world")) >>> etree.tostring(snippet) 'Hello world' > > With the tree syntax proposed in Brython it would just be > > doc <= DIV('hello '+B('world')) > > If "pythonic" means concise and readable, which one is more pythonic ? > The one that doesn't do unexpected things with operators. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 11:38 PM, Pierre Quentel wrote: > With the tree syntax proposed in Brython it would just be > > doc <= DIV('hello '+B('world')) > > If "pythonic" means concise and readable, which one is more pythonic ? Pythonic also means: If the implementation is hard to explain, it's a bad idea. What, exactly, does the sum of a string and a bolded string produce? Can you explain that easily and clearly? Don't forget that humans, as well as machines, will expect to be able to parse what's inside the parentheses without looking outside them. The DOM structure is, undeniably, quite verbose. But you could go for something with the same tree structure while a lot less wordy by simply returning self from lots of methods, thus allowing method chaining - something like this: https://github.com/Rosuav/Gypsum/blob/master/window.pike#L247 Note how the tree structure is defined by the parentheses, with ->add(...) calls creating children. (That's Pike, not Python, as I don't have a good Python example handy. The -> operator does more or less what Python's . does.) Now, I can conceive of a kind of API - an ideal API, the creature of my fancy, you know - which would be totally unobjectionable. An API, for instance, which would abolish taxes and make everything cheap, except gondolas... oh wait, wrong mailing list. To produce the HTML code hello world you might use: doc.add(Tag('DIV').add('hello ').add(Tag('B').add('world'))) And you can easily wrap that to suit, since it's surrounded by parentheses: doc.add( Tag('DIV') .add('hello ') .add(Tag('B').add('world')) ) There's no magic with operators, just simple method chaining. It's a bit more verbose than your proposed tree syntax, but not nearly as bad as the JS version; and it's not magical. Reject the idea if you will, but do at least please consider it :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
> If that's your intention, then instead of coming up with something totally > new, unpythonic and ugly, why not take the normal Python route and > implement a subset of the ElementTree API? > > Stefan Because the tree implementation in ElementTree or other tree modules in Python require a lot of typing and parenthesis To produce the HTML code hello world these modules require writing something like div = Tag('DIV') div.appendChild(TextNode('hello ')) b = Tag('B') b.appendChild(TextNode('world')) div.appendChild(b) doc.appendChild(div) With the tree syntax proposed in Brython it would just be doc <= DIV('hello '+B('world')) If "pythonic" means concise and readable, which one is more pythonic ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Pierre Quentel, 20.12.2012 10:42: > Le jeudi 20 décembre 2012 01:54:44 UTC+1, Ian a écrit : >> On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote: 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. +1 >> +1. The DOM already has a well-established API. [...] >> >> link = document.createElement('a') >> link.setAttribute("href", "http://www.python.org/";) >> link.appendChild(document.createTextNode('Python')) >> document.body.appendChild(link) > > We don't have the same point of view. Mine is to offer an alternative to > Javascript, with the simplicity and elegance of the Python syntax, for a > programer who wants to develop a web application and doesn't know Javascript. > Ultimately this means that the whole DOM API would be described without any > mention of Javascript, only with the Python API If that's your intention, then instead of coming up with something totally new, unpythonic and ugly, why not take the normal Python route and implement a subset of the ElementTree API? Stefan -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On 12/21/2012 3:31 AM, Rouslan Korneychuk wrote: Although I'm not really in favor of using an operator for this sort of thing either way, I can't help but notice the discussion seems to be limited to Python's operators. If you're implementing Python yourself, can't you define a new operator that is unambiguous? Then the result is not exactly Python. The Python 3.3 Reference defines the Python 3.3 language. Supporting only a subset (as Brython does) is okay as long as the implementation only claims support for a subset (as Brython does). -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On 12/20/2012 04:37 AM, Pierre Quentel wrote: 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" Although I'm not really in favor of using an operator for this sort of thing either way, I can't help but notice the discussion seems to be limited to Python's operators. If you're implementing Python yourself, can't you define a new operator that is unambiguous? -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Fri, Dec 21, 2012 at 1:05 PM, Steven D'Aprano wrote: > On Thu, 20 Dec 2012 18:59:39 -0500, Terry Reedy wrote: >> What Python does have is 11 versions of the augmented assignment >> statement: +=, -=, *=, /=, //=, %=, **=, >>=, <<=, &=, ^=, |=. Moreover, >> these are *intended* to be implemented in place, by mutation, for >> mutable objects, with possibly class-specific meanings. > > I don't believe that is the case. The problem is that augmented > assignment that mutates can be rather surprising to anyone who expects > "a += b" to be a short cut for "a = a + b". This is confusing only because it violates the principle that exists with methods, that it _either_ mutates _or_ returns. The augmented assignment operators must return, and in some cases also mutate, hence confusion. > One might even have a class where (say) __iadd__ is defined but __add__ > is not. That would be plausible, if it had an easy way to clone an object. This would in fact be my preferred way to do things if the clone operation is expensive - such as in this case. Adding two DOM trees could be prohibitively expensive (if the tree is deep), but parenting a tree to another is cheap. >> <= is a comparison expression operator, which is completely different. > > <= is a comparison operator for ints, floats, strings, lists, ... but not > necessarily for *everything*. That's the beauty and horror of operator > overloading. Any operator can mean anything. > > If it were intended to only return a flag, then 1) Python would enforce > that rule, and 2) the numpy people would be most upset. There's a difference between returning a different data type that makes good sense (compare two arrays and get an array of booleans) and abusing an operator for its visual characteristics. The former is a good reason to have the language grant freedom; the latter is proof that freedom can be used in many ways. I'm not saying it's always wrong, but it certainly isn't right as often as the other is. > I have no opinion on the usefulness or sensibility of using <= as an in- > place mutator method in this context, but I will say that if I were > designing my own mini-DSL, I would not hesitate to give "comparison > operators" some other meaning. Syntax should be judged in the context of > the language you are using, not some other language. If you are using a > DSL, then normal Python rules don't necessarily apply. <= in particular > looks just like a left-pointing arrow and is an obvious candidate for > overloading. But there's no corresponding => arrow! How can you make your DSL look like PHP arrays without that vital array creation operator? ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Thu, 20 Dec 2012 18:59:39 -0500, Terry Reedy wrote: >> On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel >> wrote: >>> 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. > > What Python does have is 11 versions of the augmented assignment > statement: +=, -=, *=, /=, //=, %=, **=, >>=, <<=, &=, ^=, |=. Moreover, > these are *intended* to be implemented in place, by mutation, for > mutable objects, with possibly class-specific meanings. I don't believe that is the case. The problem is that augmented assignment that mutates can be rather surprising to anyone who expects "a += b" to be a short cut for "a = a + b". py> a = [1, 2, 3]; b = [99]; another = a py> a = a + b py> print(a, another) # What I expect. [1, 2, 3, 99] [1, 2, 3] py> a = [1, 2, 3]; b = [99]; another = a py> a += b py> print(a, another) # Surprise! [1, 2, 3, 99] [1, 2, 3, 99] Whichever behaviour you pick, you're going to surprise somebody. So I wouldn't say that mutate in place is *intended* or preferred in any way, only that it is *allowed* as an optimization if the class designer prefers so. One might even have a class where (say) __iadd__ is defined but __add__ is not. [...] > <= is a comparison expression operator, which is completely different. <= is a comparison operator for ints, floats, strings, lists, ... but not necessarily for *everything*. That's the beauty and horror of operator overloading. Any operator can mean anything. If it were intended to only return a flag, then 1) Python would enforce that rule, and 2) the numpy people would be most upset. I have no opinion on the usefulness or sensibility of using <= as an in- place mutator method in this context, but I will say that if I were designing my own mini-DSL, I would not hesitate to give "comparison operators" some other meaning. Syntax should be judged in the context of the language you are using, not some other language. If you are using a DSL, then normal Python rules don't necessarily apply. <= in particular looks just like a left-pointing arrow and is an obvious candidate for overloading. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel wrote: 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. What Python does have is 11 versions of the augmented assignment statement: +=, -=, *=, /=, //=, %=, **=, >>=, <<=, &=, ^=, |=. Moreover, these are *intended* to be implemented in place, by mutation, for mutable objects, with possibly class-specific meanings. >> To add a child to a node, using an operator instead of a function call saves a lot of typing ; We agree. Just use the proper sort of operator. I believe you said elsewhere that you *are* using one augmented assignment, +=, to add a sibling. That is a proper use. I am saying to use another to add a child. <= is a comparison expression operator, which is completely different. It is just wrong for this usage. I am 99.9% sure you will come to regret it eventually. Better to make the change now than in Brython2 or Brython3. >> <= looks like a left arrow, which is a visual indication of the meaning "receive as child". |= doesn't have this arrow shape If you want to talk shape, I could argue that you should use -= for adding a sibling (horizontal link, -) and |= for adding a child (vertical link, |). Since you probably want to stick with += and like the 'arrowness' of <=, use the augmented assignment operator <<= instead of comparison operator <=. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
* Ian Kelly [2012-12-19 17:54:44 -0700]: > On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote: > > 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? > > It works for me using FF 17.0.1. I'm using FF 13 on OpenBSD and it works for me too. -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel wrote: > 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 This is the reasoning that gave us the C++ stdio system, where: cout << "Hello, world!\n"; is the way to make console output. Quite frankly, I don't like it; when I write C++ code, I use printf same as in C. I'd much rather work with methods than with operators that try to look like the flowing of data, but actually have a quite different meaning. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
Le jeudi 20 décembre 2012 01:54:44 UTC+1, Ian a écrit : > On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote: > > > 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? > > > > It works for me using FF 17.0.1. > > > > >> 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. > > > > +1. The DOM already has a well-established API. The following may > > require more typing: > > > > link = document.createElement('a') > > link.setAttribute("href", "http://www.python.org/";) > > link.appendChild(document.createTextNode('Python')) > > document.body.appendChild(link) > > > > But it is much clearer in intent. Since these methods map directly to > > DOM methods, I know exactly what I expect them to do, and I can look > > them up in the browser documentation if I have any doubts. With the > > one-liner above, I don't know exactly what that maps to in actual DOM > > calls, and so I'm a lot less clear on what exactly it is supposed to > > do. I'm not even entirely certain whether it's actually equivalent to > > my code above. > > > > I suggest that Brython should have a "low-level" DOM API that matches > > up to the actual DOM in as close to a 1:1 correspondence as possible. > > Then if you want to have a higher-level API that allows whiz-bang > > one-liners like the above, build it as an abstraction on top of the > > low-level API and include it as an optional library. This has the > > added benefit that if the user runs into an obscure bug where the > > fancy API breaks on some particular operation on some specific > > browser, they will still have the option of falling back to the > > low-level API to work around it. It would also make the conversion > > barrier much lower for web programmers looking to switch to Brython, > > if they can continue to use the constructs that they're already > > familiar with but just write them in Python instead of JavaScript. We don't have the same point of view. Mine is to offer an alternative to Javascript, with the simplicity and elegance of the Python syntax, for a programer who wants to develop a web application and doesn't know Javascript. Ultimately this means that the whole DOM API would be described without any mention of Javascript, only with the Python API With this idea in mind, asking Brython to have a Javascript-like low-level API is like asking CPython to support iteration with a low-level construct like "for i=0;i<10;i++" along with "for i in range(10)". The Python engine is stable enough that we don't have to inspect the bytecode for debugging ; similarly, when Brython is mature enough, you won't have to look at the generated Javascript code (which you can do though, eg in the console) -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
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
Re: Brython - Python in the browser
On 12/19/2012 7:54 PM, Ian Kelly wrote: On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote: 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? It works for me using FF 17.0.1. It works for me too when ignore the mistaken and misleading error message and just turn on javascript for the page. Some sites say things like "You have javascript turned off. Turn it on to see all features." 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. +1. The DOM already has a well-established API. The following may require more typing: link = document.createElement('a') link.setAttribute("href", "http://www.python.org/";) link.appendChild(document.createTextNode('Python')) document.body.appendChild(link) But it is much clearer in intent. I agree with the rest of your suggestion. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy wrote: > 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? It works for me using FF 17.0.1. >> 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. +1. The DOM already has a well-established API. The following may require more typing: link = document.createElement('a') link.setAttribute("href", "http://www.python.org/";) link.appendChild(document.createTextNode('Python')) document.body.appendChild(link) But it is much clearer in intent. Since these methods map directly to DOM methods, I know exactly what I expect them to do, and I can look them up in the browser documentation if I have any doubts. With the one-liner above, I don't know exactly what that maps to in actual DOM calls, and so I'm a lot less clear on what exactly it is supposed to do. I'm not even entirely certain whether it's actually equivalent to my code above. I suggest that Brython should have a "low-level" DOM API that matches up to the actual DOM in as close to a 1:1 correspondence as possible. Then if you want to have a higher-level API that allows whiz-bang one-liners like the above, build it as an abstraction on top of the low-level API and include it as an optional library. This has the added benefit that if the user runs into an obscure bug where the fancy API breaks on some particular operation on some specific browser, they will still have the option of falling back to the low-level API to work around it. It would also make the conversion barrier much lower for web programmers looking to switch to Brython, if they can continue to use the constructs that they're already familiar with but just write them in Python instead of JavaScript. -- http://mail.python.org/mailman/listinfo/python-list
Re: Brython - Python in the browser
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. 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 : " "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. 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? 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. 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
Re: Brython - Python in the browser
Hi Pierre this looks very interesting, thanks. But I wonder ... do you know of pyjs (pyjamas as-was)? http://pyjs.org/ I would be interested in a comparison between (the aims of) Brython and pyjs. Either way, thanks for the info. Regards Jon N -- http://mail.python.org/mailman/listinfo/python-list
Brython - Python in the browser
Hi, 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 ;-) The best introduction is to visit the Brython site (http://www.brython.info). Right click on the page with a clock and take a look at the source code : no Javascript, only Python code inside a tag