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 |