Re: Brython (Python in the browser)
In article 234a1a8d-e491-4eec-8bd5-7931cf4f7...@googlegroups.com, Pierre Quentel pierre.quen...@gmail.com 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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython Wow. Just wow. -- https://mail.python.org/mailman/listinfo/python-list
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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython I am not sure i understand the concept correct it is not serverside, i have to install the libraries on my local computer, and it is accessible via javascript, not on its own in browsers? In the future will it always be a library that has to be downloaded and installed? Could in not be implemented like an activeX plugin as flashplayer, when you come to a Brython side you have a message to download plugin? If i understand correct, now one can implement Brython script in JAVASCRIPT invoked HTML on a server, but it will not work for people surfing the web because the browsers lack support for Brython libraries? Is Brython thought to be a webapplication or can it read/write to files? So what is its future? 1. A standard incorporated and implemented by browsers? 2. A plugin like flashplayer? 3. A standalone library to be downloaded and installed on the local computer to run python scripts one make? -- https://mail.python.org/mailman/listinfo/python-list
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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython that's amazing. is there any python construct which is not usable with brython? OR, the oder way around, anything possible in JS, which does not work in brython? bg, Johannes -- Johannes Schneider Webentwicklung johannes.schnei...@galileo-press.de Tel.: +49.228.42150.xxx Galileo Press GmbH Rheinwerkallee 4 - 53227 Bonn - Germany Tel.: +49.228.42.150.0 (Zentrale) .77 (Fax) http://www.galileo-press.de/ Geschäftsführer: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker HRB 8363 Amtsgericht Bonn -- https://mail.python.org/mailman/listinfo/python-list
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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython I am not sure i understand the concept correct it is not serverside, i have to install the libraries on my local computer, and it is accessible via javascript, not on its own in browsers? In the future will it always be a library that has to be downloaded and installed? Could in not be implemented like an activeX plugin as flashplayer, when you come to a Brython side you have a message to download plugin? If i understand correct, now one can implement Brython script in JAVASCRIPT invoked HTML on a server, but it will not work for people surfing the web because the browsers lack support for Brython libraries? Is Brython thought to be a webapplication or can it read/write to files? So what is its future? 1. A standard incorporated and implemented by browsers? 2. A plugin like flashplayer? 3. A standalone library to be downloaded and installed on the local computer to run python scripts one make? Brython is made for client-side web programming, ie programs executing in a web browser. To be able to use it, all there is to do is upload the Brython distribution on the same server as the HTML pages Since it is written in standard Javascript, it is designed to be cross-browser ; it is tested on Chrome and Firefox, and is known to work with a few limitations on IE10 -- 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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython that's amazing. is there any python construct which is not usable with brython? OR, the oder way around, anything possible in JS, which does not work in brython? bg, Johannes -- Johannes Schneider Webentwicklung johannes.schnei...@galileo-press.de Tel.: +49.228.42150.xxx Galileo Press GmbH Rheinwerkallee 4 - 53227 Bonn - Germany Tel.: +49.228.42.150.0 (Zentrale) .77 (Fax) http://www.galileo-press.de/ Gesch�ftsf�hrer: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker HRB 8363 Amtsgericht Bonn The documentation maintains a list of Python features that are not supported yet. For most of them, it's just a question of time and work by the development team The only thing that is difficult to implement correctly is generators, since only few Javascript engines support yield. Brython implementation is not perfect, but for the moment it doesn't break any of the modules in the standard distribution that have been included -- https://mail.python.org/mailman/listinfo/python-list
Re: Brython (Python in the browser)
Awesome.. Wonderful work! -- https://mail.python.org/mailman/listinfo/python-list
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 : script src=/path/to/brython.js - embed Python code inside a tag script type=text/python - run the Python script on page load : body onload=brython() The Python code is translated into Javascript and executed on the fly Brython supports the DOM API, HTML5, SVG, with some syntaxic sugar to make the interface more concise (a la jQuery) ; interaction with Javascript libraries is very straightforward. The Brython site provides documentation and many examples After 1 year of intense development, Brython now covers most of the Python3 syntax and can run most of the modules of the Python3.3 standard distribution unmodified, including complex packages like unittest. The team aims at covering 100% of all of Python that makes sense in a browser environment Home page : http://www.brython.info Development site : https://bitbucket.org/olemis/brython/src Downloads : https://bitbucket.org/olemis/brython/downloads Community : https://groups.google.com/forum/?fromgroups=#!forum/brython -- https://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
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
On Sat, Dec 22, 2012 at 6:57 PM, Pierre Quentel pierre.quen...@gmail.com 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
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
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
On Sat, Dec 22, 2012 at 7:54 PM, Pierre Quentel pierre.quen...@gmail.com 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
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 10:05 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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 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 1:31 PM, Dan Sommers d...@tombstonezero.net 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 Sun, Dec 23, 2012 at 7:31 AM, Dan Sommers d...@tombstonezero.net 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 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 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
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
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
DIVhello Bworld/B/DIV
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
On Fri, Dec 21, 2012 at 11:38 PM, Pierre Quentel
pierre.quen...@gmail.com 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
DIVhello Bworld/B/DIV
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
Pierre Quentel pierre.quen...@gmail.com 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
DIVhello Bworld/B/DIV
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)
'divHello bworld/b/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 ?
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
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
DIVhello Bworld/B/DIV
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)
'divHello bworld/b/div'
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
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 '%sb%s/b' %(other,self.value)
...
'hello '+B('world')
'hello bworld/b'
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
DIVhello Bworld/B/DIV
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
ullionelitwo/ul : 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
On Sat, Dec 22, 2012 at 2:36 AM, Pierre Quentel
pierre.quen...@gmail.com 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
ullionelitwo/ul : 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 bworld/b'
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 xy: '+B('True!')
I would expect B('True!') to mean the word True! in bold; what
happens with the angle bracket in the text? Am I supposed to manually
escape that as lt; to protect it? If so, your library isn't doing
much - B might just as well be defined as
lambda s: 'b'+s+'/b'
rather than any sort of class.
ChrisA
--
http://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
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 xy: '+B('True!')
You can test this code in the console on the Brython site
(http://brython.info/tests/console_fr.html) :
doc = 'blah blah xy: '+B('True!')
It will add a text node to the document, with the string 'blah blah xy: '
followed by 'True!' in bold characters
- Pierre
--
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
On Fri, Dec 21, 2012 at 9:16 AM, Pierre Quentel
pierre.quen...@gmail.com 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
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 1:59 PM, Pierre Quentel pierre.quen...@gmail.com 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
On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel
pierre.quen...@gmail.com 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 = p/p'
will add literal text, not a paragraph object, right? That's
definitely what I would expect.
doc = 'blah blah xy: '+B('True!')
It will add a text node to the document, with the string 'blah blah xy: '
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 3:52 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Dec 22, 2012 at 3:36 AM, Pierre Quentel
pierre.quen...@gmail.com 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 = p/p'
will add literal text, not a paragraph object, right? That's
definitely what I would expect.
doc = 'blah blah xy: '+B('True!')
It will add a text node to the document, with the string 'blah blah xy: '
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
Héllo,
doc = 'blah blah xy: '+B('True!')
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 4:45 PM, Ian Kelly ian.g.ke...@gmail.com 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
On Fri, Dec 21, 2012 at 4:45 PM, Ian Kelly ian.g.ke...@gmail.com 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 Sat, Dec 22, 2012 at 10:57 AM, Ian Kelly ian.g.ke...@gmail.com 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 Sat, Dec 22, 2012 at 10:50 AM, Amirouche Boubekki amirouche.boube...@gmail.com 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 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
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
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 tjre...@udel.edu 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;i10;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
On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel pierre.quen...@gmail.com 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
* Ian Kelly ian.g.ke...@gmail.com [2012-12-19 17:54:44 -0700]: On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy tjre...@udel.edu 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 pierre.quen...@gmail.com 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
On Thu, 20 Dec 2012 18:59:39 -0500, Terry Reedy wrote: On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel pierre.quen...@gmail.com 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 Fri, Dec 21, 2012 at 1:05 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info 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. tongue location=cheekBut there's no corresponding = arrow! How can you make your DSL look like PHP arrays without that vital array creation operator?/tongue ChrisA -- 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 script type=text/python. You will
notice the inclusion of a script brython.js in the HEAD section, and a call to
the function brython() when the page is loaded : that's all it takes
Brython is both a Python to Javascript translator, and a Python interface to
the Document Object Model. For instance, access to a DOM element by its id is
done by
doc[element_id]
where doc is a keyword referencing the document. To create an element, for
instance an HTML anchor :
doc = A('Python',href=http://www.python.org;)
The element is created by a built-in class called A, like the HTML tag ; it is
inserted in the document by the operator = which is obviously not lesser or
equal, but an arrow meaning add child
Brython is at a very early stage, but already usable : you can visit the
gallery with a few applications using Ajax calls, HTML5 local storage, drag and
drop, canvas etc. The performance is below pure Javascript, but not by far :
the 3D demo is almost as fluid as its Javascript equivalent
It still lacks important features of Python, mostly list comprehensions and
classes ; the documentation is limited, there are bugs, the testing process is
rudimentary, performance can still improve. For all its current limitations,
since I first announced it to a limited audience, the reactions have been very
positive (see for instance this blog entry by François Dion :
http://raspberry-python.blogspot.fr/2012/12/brython-browser-python.html)
If you are interested in this project, there are many ways to contribute :
- report bugs or suggest new features on the issue tracker
(http://code.google.com/p/brython/issues/list) : there is a console at
http://brython.info/tests/console_en.html to test online, or you can download a
local distribution from the development site
- write code : the priority is to extend the built-in Javascript modules
(time.js, math.js, etc) - I'm ready to support developers willing to work on
this
- contribute to the documentation, translate into other languages, write a
tutorial, etc
- promote Brython in forums, blogs, tweets, events, etc
- if you develop demos or apps with Brython, send a link to the community
(https://groups.google.com/forum/?fromgroups=#!forum/brython), it will be added
to the gallery on brython.info
Enjoy !
Pierre
--
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
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
On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy tjre...@udel.edu 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 7:54 PM, Ian Kelly wrote:
On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy tjre...@udel.edu 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
