Path: csiph.com!usenet.pasdenom.info!aioe.org!news.stack.nl!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
Newsgroups: comp.lang.python
Date: Thu, 20 Dec 2012 01:42:01 -0800 (PST)
In-Reply-To: <mailman.1082.1355964916.29569.python-list@python.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=193.49.124.107; posting-account=cEyVOAoAAAAQ26Zg5AgQClqyybEKp-yz
References: <c0be76ec-d55b-4f6c-9892-a80b482ff5bb@googlegroups.com> <50D256B3.4070709@udel.edu> <mailman.1082.1355964916.29569.python-list@python.org>
User-Agent: G2/1.0
MIME-Version: 1.0
Subject: Re: Brython - Python in the browser
From: Pierre Quentel <pierre.quentel@gmail.com>
To: comp.lang.python@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Python <python-list@python.org>
Precedence: list
Message-ID: <mailman.1094.1355999272.29569.python-list@python.org>
Lines: 106
NNTP-Posting-Host: 2001:888:2000:d::a6
Xref: csiph.com comp.lang.python:35187

Le jeudi 20 d=E9cembre 2012 01:54:44 UTC+1, Ian a =E9crit=A0:
> On Wed, Dec 19, 2012 at 5:07 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>=20
> > That says that my browser, Firefox 17, does not support HTML5. Golly ge=
e. I
>=20
> > don't think any browser support5 all of that moving target, and Gecko
>=20
> > apparently supports about as large a subset as most.
>=20
> > https://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
>=20
> > It is possible the FF still does not support the particular feature nee=
ded
>=20
> > for the clock, but then the page should say just that. Has the latest F=
F
>=20
> > (17) actually been tested?
>=20
>=20
>=20
> It works for me using FF 17.0.1.
>=20
>=20
>=20
> >> To create an element, for instance an HTML anchor :
>=20
> >> doc <=3D A('Python',href=3D"http://www.python.org")
>=20
> >
>=20
> >
>=20
> > To me, that is a awful choice and I urge you to change it.
>=20
>=20
>=20
> +1.  The DOM already has a well-established API.  The following may
>=20
> require more typing:
>=20
>=20
>=20
> link =3D document.createElement('a')
>=20
> link.setAttribute("href", "http://www.python.org/")
>=20
> link.appendChild(document.createTextNode('Python'))
>=20
> document.body.appendChild(link)
>=20
>=20
>=20
> But it is much clearer in intent.  Since these methods map directly to
>=20
> DOM methods, I know exactly what I expect them to do, and I can look
>=20
> them up in the browser documentation if I have any doubts.  With the
>=20
> one-liner above, I don't know exactly what that maps to in actual DOM
>=20
> calls, and so I'm a lot less clear on what exactly it is supposed to
>=20
> do.  I'm not even entirely certain whether it's actually equivalent to
>=20
> my code above.
>=20
>=20
>=20
> I suggest that Brython should have a "low-level" DOM API that matches
>=20
> up to the actual DOM in as close to a 1:1 correspondence as possible.
>=20
> Then if you want to have a higher-level API that allows whiz-bang
>=20
> one-liners like the above, build it as an abstraction on top of the
>=20
> low-level API and include it as an optional library.  This has the
>=20
> added benefit that if the user runs into an obscure bug where the
>=20
> fancy API breaks on some particular operation on some specific
>=20
> browser, they will still have the option of falling back to the
>=20
> low-level API to work around it.  It would also make the conversion
>=20
> barrier much lower for web programmers looking to switch to Brython,
>=20
> if they can continue to use the constructs that they're already
>=20
> 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 Ja=
vascript, with the simplicity and elegance of the Python syntax, for a prog=
ramer who wants to develop a web application and doesn't know Javascript. U=
ltimately 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=3D0;i<10;i++" along with "for i in range(10)". The Python engin=
e 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)