sgzwiz / brython

Automatically exported from code.google.com/p/brython
BSD 3-Clause "New" or "Revised" License
0 stars 1 forks source link

put non-standard builtins into a module #71

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Linters like PyFlakes will cause errors on un-defined names.  brython exposes 
its entire API via special built-in names, which means that any program that 
uses one of those names looks erroneous.  It also makes it hard to create a 
fake version of those APIs.

Plus, it's always possible that existing Python libraries that might be useful 
in a browser-based application will define some of these names themselves (it's 
not hard to imagine a library that defined a variable called "CENTER").

Finally, the built-in list of HTML names is missing tons of tags that are 
present in HTML5 and therefore accessible to modern browsers, like, for 
example, SVG.  If these all get added as builtins, this will make the problem 
even worse.  If these were in their own namespace, it would be possible to 
create unknown tags by having a getattr hook, like "import brython; 
brython.tags.ELLIPSE" could work even if the module doesn't specifically know 
about ELLIPSE.

Original issue reported on code.google.com by Glyph.Lefkowitz on 13 Feb 2013 at 4:44

GoogleCodeExporter commented 9 years ago
Also, there's a good reason that 'import *' is discouraged, and this 
effectively means that you have no choice but to always use 'import *'.

Original comment by Glyph.Lefkowitz on 13 Feb 2013 at 4:48

GoogleCodeExporter commented 9 years ago
Thanks for the feedback

Brython is an implementation of Python adapted to the browser. I chose to add 
some built-in names to the namespace because they are likely to be used very 
often when building a web page, which is its main concern

The risk of conflict with other names exists, but in my life as a Python 
programmer I also had problems because I wrongly used built-in names like "dir" 
; the interpreter gave no error message so I had to understand why "dir(foo)" 
didn't work 20 lines after I had written "dir=0"

I assume that Brython developers will quickly get used to this specific 
namespace (the names are uppercase, it helps ; Python developers rarely use 
uppercase for variable names) ; in fact the only name conflicts I had so far 
are with Javascript built-in names such as "status"

I took the list of HTML4 and 5 tags from the W3C site, I don't think I missed 
tons of them. Which ones do you think are missing ? You mention SVG, but in 
fact this name *is* in the Brython namespace, as you can see on the SVG demo on 
the gallery ; the shapes in SVG are accessed by SVG.text, SVG.path, SVG.ellipse 
etc. (I just forgot to mention it in the documentation)

I'm sorry but I don't understand your comment about "import *"

Original comment by pierre.q...@gmail.com on 14 Feb 2013 at 9:34

GoogleCodeExporter commented 9 years ago
I also support the idea of a separate namespace for Brython-specific members, 
and I am aware that other people will second this idea too. The point of having 
a separate module so you don't add members to Python's default builtins makes 
it easier, as Glyph said, to use normal Python editors, for example. Moreover, 
I foresee the possibility to create a Python package called Brython.py which 
would implement the same names as the original JavaScript Brython and that 
could be used, say, to manipulate a wx canvas, or to generate JavaScript from 
my Python project.

Regarding the discouragement of "import *", in general the philosophy of Python 
is that

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
[...]
Namespaces are one honking great idea -- let's do more of those!

If you "import *" suddenly you have lots of members which you don't know where 
they come from. If you want to look for the sourcecode of a function or a class 
and you know where it is located via its namespace it is much easier.

Original comment by pybonacc...@gmail.com on 19 Feb 2013 at 12:30

GoogleCodeExporter commented 9 years ago
I agree..  I think it would be best to create a dom module, and put all the dom 
objects in there.  if someone doesn't want to respect namespaces, they only 
need to add a single line of code

from dom import *

This would also allow other python implementations to mimic brython if they 
want to.
Just my 2 cents.. :)

Billy

Original comment by billy.earney@gmail.com on 23 Feb 2013 at 11:45

GoogleCodeExporter commented 9 years ago
After a discussion on the Brython forum, and reading other comments on the same 
topic, I am following your advice. I introduced 2 modules, "html" and "svg", 
that hold the names of HTML and SVG tags

They are imported like normal Python modules ; since Brython now supports "from 
X import Y", developers have the choice between :

from html import * ("frowned upon", I know...)
from html import <the tags needed in the script>
import html

and the same for SVG

Original comment by pierre.q...@gmail.com on 27 Feb 2013 at 4:30

GoogleCodeExporter commented 9 years ago
cool..  Thanks!

Original comment by billy.earney@gmail.com on 27 Feb 2013 at 5:20