|
From: Bruce S. <bas...@nc...> - 2010-09-16 04:00:44
|
Here I start a new thread with the proposal that we collectively come
up with documentation for those users who want to be careful about
namespace cleanliness. Below I reproduce a sample of an import
strategy that worked for gas.py as an alternative to "from visual
import *". It isn't fully restrictive, because for purposes of
completeness I've imported all of the vector stuff, all of the
primitives, and materials (which aren't used in gas.py), so it's just
a proof of concept. I'm suggesting that working together we ought to
be able to come up with one or a few recommended schemes for use when
"from visual import *" is not suitable. I want to emphasize that I
believe strongly that the latter scheme has its place, but it is
desirable to provide guidance for an alternative approach that doesn't
import all of math and all of numpy.
You're invited to post what you think would be a useful and
appropriate example of import strategy, with my own example being a
proof of concept but presumably not exactly what we might all agree is
most useful as advice.
Further caveat: Although gas.py is a pretty good test case, since it
uses visual objects, math, and numpy, it may well be that I've missed
something.
Bruce Sherwood
Example:
from visual.cvisual import (vector, mag, mag2, norm, dot, cross, rotate,
comp, proj, diff_angle, rate, waitclose)
from visual.primitives import (arrow, cylinder, cone, sphere, box, ring, label,
frame, pyramid, ellipsoid, curve,
faces, convex, helix,
points, text, distant_light, local_light)
from visual.ui import display
import visual.crayola as color
import visual.materials as materials
import visual.site_settings
import atexit as _atexit
_atexit.register(waitclose)
from math import pi, sin, cos, exp
from numpy import (sqrt, array, newaxis, add, less_equal, identity,
sort, nonzero, greater_equal, arange)
from visual.graph import (gdisplay, gcurve, ghistogram)
from random import random
|