visualpython-users

[Visualpython-users] polluted name space of the visual module

[Guy K. K. <g....@ma...>]

Hi,

just trying to hunt down on how to delete a scene, so I can create a new one 
within the same running program. Trying to hunt this down I've been wondering 
why there are so many things within the visual module. It is absolutely a 
highly polluted name space. It's happening already in the visual.__init__ 
module through two snowball imports:

from math import *
from numpy import *

Would it be possible to refactor VPython in the future to be a little bit 
better behaved and just import numpy and math and use the functions using the 
dot notation (numpy.array, math.sin, ...) rather than them blended *all* 
directly into the name space?

All Python style guides tell to *not* pollute the name space. Here's one from 
the "Code Like a Pythonista: Idiomatic Python" from David Goodger's PyCon 2007 
talk:

http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#importing

Let's try to make Visual Python a good Python citizen!

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] polluted name space of the visual module

[Guy K. K. <g....@ma...>]

A bit more on why namespace pollution is bad, particularly in this case:

On Sun, 28 Jun 2009 12:50:24 Guy K. Kloss wrote:
> from math import *
> from numpy import *

math and numpy both define certain functions and constants. So there's already 
a clash happening on the import with the latter import overwriting certain 
functionality of the former. NumPy provides quite a few functions that behave 
(almost) the same as the ones from math (e. g. abs(), sin(), ...). But the 
NumPy versions mostly also work on arrays, whereas the ones from math do not. 
So there is potentially already quite some confusion for the developer (of the 
VPython module).

Own tests resulted in the math versions of the functions to be more performant 
than the NumPy version. This is not unusual, as they don't have to deal with 
arrays and can be launched directly at the passed parameters.

If now users also naively import "from visual import *" they will have (A) a 
totally polluted name space themselves, but (B) also not have the choice any 
more over what *exact* functions they are using. In many cases that might not 
matter, but it can be very dangerous in cases of reproducibility or when one 
*depends* on a specific behaviour!

So just for a minor convenience or laziness of the developer everybody further 
downstream is potentially suffering of the snowball imports. There *are* valid 
use cases for snowball imports, but they are not like this (e. g. developing a 
package to offer functions, which in turn are implemented in various sub 
modules. Then the __init__ of the package may snowball import these to expose 
the API to the outside.).

So, please let's help clean up this mess!

Guy

-- 
Guy K. Kloss
Institute of Information and Mathematical Sciences
Te Kura Pūtaiao o Mōhiohio me Pāngarau
Massey University, Albany (North Shore City, Auckland)
473 State Highway 17, Gate 1, Mailroom, Quad B Building
voice: +64 9 414-0800 ext. 9585   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss