Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #35144 > unrolled thread

Brython - Python in the browser

Back to article view | Back to comp.lang.python

Contents

  Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-19 10:19 -0800
    Re: Brython - Python in the browser jkn <jkn_gg@nicorp.f9.co.uk> - 2012-12-19 14:59 -0800
    Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-19 19:07 -0500
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:37 -0800
        Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-20 20:56 +1100
        Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-20 18:59 -0500
          Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-21 02:05 +0000
            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-21 16:07 +1100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:16 -0800
            Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 17:52 +0100
            Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 11:31 -0700
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 12:59 -0800
                Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 14:17 -0700
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 12:59 -0800
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:16 -0800
        Re: Brython - Python in the browser Rouslan Korneychuk <rouslank@msn.com> - 2012-12-21 03:31 -0500
          Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-21 04:44 -0500
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:37 -0800
    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-19 17:54 -0700
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:42 -0800
        Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 12:25 +0100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 04:38 -0800
            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-21 23:57 +1100
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 07:36 -0800
                Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 02:48 +1100
                  Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:36 -0800
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 09:52 +1100
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:45 -0700
                    Re: Brython - Python in the browser Amirouche Boubekki <amirouche.boubekki@gmail.com> - 2012-12-22 00:50 +0100
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:51 -0700
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:59 -0800
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:59 -0800
                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-21 16:57 -0700
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 11:08 +1100
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:57 -0800
                        Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 19:31 +1100
                          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 00:54 -0800
                            Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 20:08 +1100
                              Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-22 11:05 +0000
                                Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 23:11 +1100
                                  Re: Brython - Python in the browser Dan Sommers <dan@tombstonezero.net> - 2012-12-22 20:31 +0000
                                    Re: Brython - Python in the browser Ian Kelly <ian.g.kelly@gmail.com> - 2012-12-22 13:53 -0700
                                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-23 08:49 +1100
                          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 00:54 -0800
                      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 23:57 -0800
                    Re: Brython - Python in the browser Chris Angelico <rosuav@gmail.com> - 2012-12-22 11:09 +1100
                  Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 08:36 -0800
              Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 07:36 -0800
            Re: Brython - Python in the browser Duncan Booth <duncan.booth@invalid.invalid> - 2012-12-21 13:14 +0000
              Re: Brython - Python in the browser Stefan Behnel <stefan_ml@behnel.de> - 2012-12-21 14:34 +0100
          Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-21 04:38 -0800
          Re: Brython - Python in the browser Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-12-22 02:31 +0000
      Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-20 01:42 -0800
    Re: Brython - Python in the browser Terry Reedy <tjreedy@udel.edu> - 2012-12-19 21:46 -0500
    Re: Brython - Python in the browser Jamie Paul Griffin <jamie@kode5.net> - 2012-12-20 11:32 +0000
    Re: Brython - Python in the browser Pierre Quentel <pierre.quentel@gmail.com> - 2012-12-22 01:01 -0800

Page 1 of 3  [1] 2 3  Next page →

#35144 — 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

[toc] | [next] | [standalone]

#35163

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

[toc] | [prev] | [next] | [standalone]

#35165

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

[toc] | [prev] | [next] | [standalone]

#35184

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

[toc] | [prev] | [next] | [standalone]

#35186

On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel
<pierre.quentel@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

[toc] | [prev] | [next] | [standalone]

#35241

> On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel
> <pierre.quentel@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

[toc] | [prev] | [next] | [standalone]

#35259

On Thu, 20 Dec 2012 18:59:39 -0500, Terry Reedy wrote:

>> On Thu, Dec 20, 2012 at 8:37 PM, Pierre Quentel
>> <pierre.quentel@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

[toc] | [prev] | [next] | [standalone]

#35267

On Fri, Dec 21, 2012 at 1:05 PM, Steven D'Aprano
<steve+comp.lang.python@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="cheek">But there's no corresponding => arrow! How
can you make your DSL look like PHP arrays without that vital array
creation operator?</tongue>

ChrisA

[toc] | [prev] | [next] | [standalone]

#35303

> <= 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

[toc] | [prev] | [next] | [standalone]

#35308

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

[toc] | [prev] | [next] | [standalone]

#35313

On Fri, Dec 21, 2012 at 9:16 AM, Pierre Quentel
<pierre.quentel@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()?

[toc] | [prev] | [next] | [standalone]

#35317

> 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

[toc] | [prev] | [next] | [standalone]

#35319

On Fri, Dec 21, 2012 at 1:59 PM, Pierre Quentel
<pierre.quentel@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)

[toc] | [prev] | [next] | [standalone]

#35318

> 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

[toc] | [prev] | [next] | [standalone]

#35304

> <= 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

[toc] | [prev] | [next] | [standalone]

#35277

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?

[toc] | [prev] | [next] | [standalone]

#35280

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

[toc] | [prev] | [next] | [standalone]

#35188

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

[toc] | [prev] | [next] | [standalone]

#35170

On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy <tjreedy@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.

[toc] | [prev] | [next] | [standalone]

#35185

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 <tjreedy@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;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)

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web