Brython - Python in the browser

Discussion in 'Python' started by Pierre Quentel, Dec 19, 2012.

  1. 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 allit 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 ; itis 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 andclasses ; 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 havebeen 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
     
    Pierre Quentel, Dec 19, 2012
    #1
    1. Advertising

  2. Pierre Quentel

    jkn Guest

    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
     
    jkn, Dec 19, 2012
    #2
    1. Advertising

  3. Pierre Quentel

    Terry Reedy Guest

    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_(HTML5)
    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
     
    Terry Reedy, Dec 20, 2012
    #3
  4. Pierre Quentel

    Ian Kelly Guest

    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_(HTML5)
    > 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.
     
    Ian Kelly, Dec 20, 2012
    #4
  5. Pierre Quentel

    Terry Reedy Guest

    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_(HTML5)
    >> 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
     
    Terry Reedy, Dec 20, 2012
    #5
  6. 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_(HTML5)
    >
    > 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 bemanaged 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
     
    Pierre Quentel, Dec 20, 2012
    #6
  7. 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_(HTML5)
    >
    > 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 bemanaged 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
     
    Pierre Quentel, Dec 20, 2012
    #7
  8. 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_(HTML5)

    >
    > > 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)
     
    Pierre Quentel, Dec 20, 2012
    #8
  9. 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_(HTML5)

    >
    > > 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)
     
    Pierre Quentel, Dec 20, 2012
    #9
  10. 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
     
    Chris Angelico, Dec 20, 2012
    #10
  11. * 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_(HTML5)
    > > 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.
     
    Jamie Paul Griffin, Dec 20, 2012
    #11
  12. Pierre Quentel

    Terry Reedy Guest


    > 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
     
    Terry Reedy, Dec 20, 2012
    #12
  13. 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
     
    Steven D'Aprano, Dec 21, 2012
    #13
  14. 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?
     
    Rouslan Korneychuk, Dec 21, 2012
    #14
  15. Pierre Quentel

    Terry Reedy Guest

    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
     
    Terry Reedy, Dec 21, 2012
    #15
  16. 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
     
    Stefan Behnel, Dec 21, 2012
    #16
  17. > 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

    <DIV>hello <B>world</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 ?
     
    Pierre Quentel, Dec 21, 2012
    #17
  18. > 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

    <DIV>hello <B>world</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 ?
     
    Pierre Quentel, Dec 21, 2012
    #18
  19. 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

    <DIV>hello <B>world</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
     
    Chris Angelico, Dec 21, 2012
    #19
  20. 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
    >>
    >> <DIV>hello <B>world</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)

    > '<div>Hello <b>world</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
     
    Stefan Behnel, Dec 21, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lauchlan M
    Replies:
    2
    Views:
    446
    John Saunders
    Aug 17, 2003
  2. DKM
    Replies:
    15
    Views:
    784
  3. xyZed
    Replies:
    9
    Views:
    646
    Big Bill
    May 12, 2004
  4. ai4u
    Replies:
    0
    Views:
    2,839
  5. Pierre Quentel

    Brython (Python in the browser)

    Pierre Quentel, Dec 27, 2013, in forum: Python
    Replies:
    6
    Views:
    163
Loading...

Share This Page