visualpython-users

[Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

At http://vpython.org/contents/history.html (the "Recent developments"
section of vpython.org) you can download an experimental beta version
of VPython for Python 3.1 for Windows. The font modules included in
this VPython installer have been updated to work with Python 3.1, but
tested only to the extent that they work with VPython. It is quite
possible that additional work is needed to make them fully functional
with Python 3.1.

This beta version for Windows seems to work correctly, but it's
labeled "beta" because this represents a pretty big change. If you're
a bit adventurous I encourage you to use the new version and report
any problems to this forum.

I have not been able to produce a version for Python 3.1 for the Mac
because there isn't yet a Mac installer for numpy, and I have been
unsuccessful in trying to build numpy from source on the Mac. I also
have not succeeded in building VPython on Ubuntu.

The Python 2 series ended with Python 2.7. The Python 3 series cleans
up some accumulated infelicities in the Python language, at the cost
of some incompatibilities. The only significant incompatibility that
affects nearly all Python 2 program is a change to the print
statement:

Python 2: print "momentum =", m*v
Python 3: print("momentum =", m*v)

The old form, without the newly required parentheses, gives an error
in Python 3.x. The new form can be used with Python 2.x, but it
displays the parentheses, which may look a bit odd.

With Python 3.x, it is no longer necessary to use from __future__
import division in order to have 1/2 give 0.5 instead of 0. However,
it doesn't matter if the statement is left in the program; it's simply
ignored.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Wouldn't this be a good point of time to clean up a little bit of the mess 
with the wild card imports and the polluted name spaces?

After all, coding for Py3k draws some changes in style after it anyway, so one 
cannot expect their code to work without changes anymore anyway. I guess this 
might be the ideal point in time to sanitise things in the code base that have 
been a bit of an issue in the past.

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. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

Yes, that's a good idea. I myself am not currently up to doing this,
but if I recall correctly you had looked into this, yes? It should be
done in such a way that the novice can still get everything with "from
visual import *", but there should be an optional restrictive import
for experts.

Bruce Sherwood

On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
> Wouldn't this be a good point of time to clean up a little bit of the mess
> with the wild card imports and the polluted name spaces?
>
> After all, coding for Py3k draws some changes in style after it anyway, so one
> cannot expect their code to work without changes anymore anyway. I guess this
> might be the ideal point in time to sanitise things in the code base that have
> been a bit of an issue in the past.
>
> 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. 9266   fax: +64 9 441-8181
> G....@ma... http://www.massey.ac.nz/~gkloss
>
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[C A. R. <an...@ex...>]

>On Tue, Sep 14, 2010 at 6:30 PM, Bruce Sherwood <bas...@nc...> wrote:
>> On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
>>
>> Wouldn't this be a good point of time to clean up a little bit of the mess
>> with the wild card imports and the polluted name spaces?
>
> Yes, that's a good idea. I myself am not currently up to doing this,
> but if I recall correctly you had looked into this, yes? It should be
> done in such a way that the novice can still get everything with "from
> visual import *", but there should be an optional restrictive import
> for experts.

I know visual had it roots in assisting physics students, but it seems
to have really grown beyond that; too strict adherence will deter
others from furthering it's reach.  In my case, I came across visual
while developing a real-time, distributed, generic data
visualizer/analyzer, and the namespace thing was a huge... annoyance
:-).

Personally, I think the "visual" package should provide specific
modules for the various things it supports, in a clean, pythonic
manner.  An alternate "visualphysics" package could perform the
wildcard imports from numpy and friends to create an environment
targeted at simulations of physical systems.

Visual to me is, and to others I introduce it as, a simple, intuitive,
and _generic_ way to design and control 3D spaces from python; physics
is only one use case.  I don't know how hard it would be to retain the
current functionality _and_ clean up the namespace... which is why i
suggest 2 packages, or something like:

from visual.physics import *

at the least, the base "visual" package should be the pythonic version.

C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

My strong preference and need is for the import by novices (not just
physics students, but other novices as well) to remain what it has
been, "from visual import *", and for the expert, clean import to be
more complex if necessary. However, I'm open to some other one-line
statement for novices if that is what's necessary to satisfy expert
needs. Someone needs to take this on as a project and make a specific
proposal to the community.

Bruce Sherwood

On Tue, Sep 14, 2010 at 6:52 PM, C Anthony Risinger <an...@ex...> wrote:
>>On Tue, Sep 14, 2010 at 6:30 PM, Bruce Sherwood <bas...@nc...> wrote:
>>> On Tue, Sep 14, 2010 at 3:27 PM, Guy K. Kloss <g....@ma...> wrote:
>>>
>>> Wouldn't this be a good point of time to clean up a little bit of the mess
>>> with the wild card imports and the polluted name spaces?
>>
>> Yes, that's a good idea. I myself am not currently up to doing this,
>> but if I recall correctly you had looked into this, yes? It should be
>> done in such a way that the novice can still get everything with "from
>> visual import *", but there should be an optional restrictive import
>> for experts.
>
> I know visual had it roots in assisting physics students, but it seems
> to have really grown beyond that; too strict adherence will deter
> others from furthering it's reach.  In my case, I came across visual
> while developing a real-time, distributed, generic data
> visualizer/analyzer, and the namespace thing was a huge... annoyance
> :-).
>
> Personally, I think the "visual" package should provide specific
> modules for the various things it supports, in a clean, pythonic
> manner.  An alternate "visualphysics" package could perform the
> wildcard imports from numpy and friends to create an environment
> targeted at simulations of physical systems.
>
> Visual to me is, and to others I introduce it as, a simple, intuitive,
> and _generic_ way to design and control 3D spaces from python; physics
> is only one use case.  I don't know how hard it would be to retain the
> current functionality _and_ clean up the namespace... which is why i
> suggest 2 packages, or something like:
>
> from visual.physics import *
>
> at the least, the base "visual" package should be the pythonic version.
>
> C Anthony
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

Maybe the desire for a cleaner import of visual isn't a big deal. I
put the following code in site-packages/visual/basic.py:

from . cvisual import (vector, mag, mag2, norm, 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
from . import crayola as color
from . import materials
from . import site_settings
import atexit as _atexit
_atexit.register(waitclose)
scene = display()

Next I successfully ran some little programs such as this one:

import visual.basic as vb
vb.box(pos=(1.5,0,0), color=vb.color.orange, material=vb.materials.wood)
C = vb.curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=vb.color.cyan)
print(C.pos)
vb.scene.mouse.getclick()
scene2 = vb.display(x=400)
vb.sphere()

I haven't done extensive testing, and I'm interested in suggestions
for improvement. The key point of course is that this doesn't import
all of math and numpy, but leaves "from visual import *" still
available.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

A colleague points out that visual.basic (Visual Basic) maybe isn't
the most intelligent nomenclature....

So if this idea has merit, there is at least the question of what the
file should really be named.

Bruce Sherwood

On Wed, Sep 15, 2010 at 10:24 AM, Bruce Sherwood <bas...@nc...> wrote:
> Maybe the desire for a cleaner import of visual isn't a big deal. I
> put the following code in site-packages/visual/basic.py:
>
> from . cvisual import (vector, mag, mag2, norm, 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
> from . import crayola as color
> from . import materials
> from . import site_settings
> import atexit as _atexit
> _atexit.register(waitclose)
> scene = display()
>
> Next I successfully ran some little programs such as this one:
>
> import visual.basic as vb
> vb.box(pos=(1.5,0,0), color=vb.color.orange, material=vb.materials.wood)
> C = vb.curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=vb.color.cyan)
> print(C.pos)
> vb.scene.mouse.getclick()
> scene2 = vb.display(x=400)
> vb.sphere()
>
> I haven't done extensive testing, and I'm interested in suggestions
> for improvement. The key point of course is that this doesn't import
> all of math and numpy, but leaves "from visual import *" still
> available.
>
> Bruce Sherwood
>

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[C A. R. <an...@ex...>]

On Wed, Sep 15, 2010 at 11:51 AM, Bruce Sherwood <bas...@nc...> wrote:
> A colleague points out that visual.basic (Visual Basic) maybe isn't
> the most intelligent nomenclature....
>
> So if this idea has merit, there is at least the question of what the
> file should really be named.

My thought was to create a dedicated namespace/module, for these
"specialized" environments; something like:

visual.framework.physics
visual.framework.<insert here>

this would open the door for other special interest groups, if any, to
create there own modules that import whatever they want to create a
base environment for the novices in their particular field.

additionally...

from visual.framework.physics import *

is still a pretty easy one-liner.  Relating to your "basic.py"
example, my preference would be that everything exist in it's own
module, example:

from visual.vector import mag, mag2, ..., ...

I see that primitives/ui/materials/etc. (from your example) seem to
already be nicely broken up.  I'm not very familiar with visual
internally, having only used it in projects.  In short, I guess I'm
just the kind of developer that likes everything to be explicitly
included, and nothing else, but that's just me :-).

At any rate, visual is a great tool, and I would like to see it become
flexible enough for embedding, and any other use cases; great stuff.

C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

For lots of reasons (including existing documentation and programs,
not restricted to the documentation and programs that come with
VPython), unless there are extremely strong arguments to justify a
change, I want to leave "from visual import *" in place, a "batteries
included" environment (also a pythonic concept). But I'm happy to
introduce a new way to import visual that is restrictive. I'm
certainly not tied to the little experiment I've just carried out. As
you say, perhaps my little file should be split into separate pieces.

Bruce SherwoodOn Wed, Sep 15, 2010 at 11:22 AM, C Anthony Risinger
<an...@ex...> wrote:
> On Wed, Sep 15, 2010 at 11:51 AM, Bruce Sherwood <bas...@nc...> wrote:
>> A colleague points out that visual.basic (Visual Basic) maybe isn't
>> the most intelligent nomenclature....
>>
>> So if this idea has merit, there is at least the question of what the
>> file should really be named.
>
> My thought was to create a dedicated namespace/module, for these
> "specialized" environments; something like:
>
> visual.framework.physics
> visual.framework.<insert here>
>
> this would open the door for other special interest groups, if any, to
> create there own modules that import whatever they want to create a
> base environment for the novices in their particular field.
>
> additionally...
>
> from visual.framework.physics import *
>
> is still a pretty easy one-liner.  Relating to your "basic.py"
> example, my preference would be that everything exist in it's own
> module, example:
>
> from visual.vector import mag, mag2, ..., ...
>
> I see that primitives/ui/materials/etc. (from your example) seem to
> already be nicely broken up.  I'm not very familiar with visual
> internally, having only used it in projects.  In short, I guess I'm
> just the kind of developer that likes everything to be explicitly
> included, and nothing else, but that's just me :-).
>
> At any rate, visual is a great tool, and I would like to see it become
> flexible enough for embedding, and any other use cases; great stuff.
>
> C Anthony

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

On Thu, 16 Sep 2010 06:49:55 Bruce Sherwood wrote:
> I want to leave "from visual import *" in place,

I strongly disagree.

> a "batteries included" environment (also a pythonic concept).

"Batteries included" is, but not batteries constantly inserted and 
discharging!

As I sais, with Py3k you're facing a change in code and samples anyway. And I 
think that something like C Anthony's suggestion gives the freedom of 
retaining backwards compatibility with only a minor fix, just for convenience 
reason. But the *norm* in Python is to have things split up into places where 
they belong, and to not overshadow things (paradigm "explicit is better than 
implicit"). So if I want to use the cosine function (cos()), then I'm either 
going to import it *myself* from math or numpy, depending on what I want. And 
I do not want to be tripped up by some awkward changes as an unexpected one is 
being called. Besides, things like these mathematical functions don't really 
belong into a package called "visual" anyway.

So, my suggestion:

 * Use the convenience of a Py3k switch to sanitise the API.

 * Remove all the wild card imports, and have the user import what they need.

 * For newbie's convenience, provide a "physicists make happy" package that
   does the wild card imports all across the board.
   (Even though I'm of the opinion that this dirty short cut creates more
   head scratching in the future than it helps up front ...)

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. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

Suppose we don't add any new file to site-packages/visual but simply
document something like the following, for the ultimate flexibility
that some people want and need. Here is a little program that
explicitly imports individual components and then uses them:

# Very explicit imports:
from visual.cvisual import (vector, mag, mag2, norm, 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)
scene = display()
# Now use this stuff:
box(pos=(1.5,0,0), color=color.orange, material=materials.wood)
C = curve(pos=[(0,0,0),(1,0,0),(1,1,0),(0,1,0)], color=color.cyan)
print(C.pos)
scene.mouse.getclick()
scene2 = display(x=400)
sphere()

I don't know whether the imports listed above really do span the
space, which requires more testing.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Bruce S. <bas...@nc...>]

Here's another successful test. I replaced the import statements at
the start of the example program gas.py with the following import
statements, and deleted the old Numeric code in a try structure:

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

This could have been more selective, since gas.py uses only a few of
the vector and primitive features. Also, gas.py already has a scene =
display(....) statement.

A subtle point that one should be aware of: In visual's __init__.py
there is some complex machinery to deal with the fact that when, for
example, you're taking the square root of a scalar you want to use the
math module's sqrt, because it is much faster than using numpy's sqrt.
On the other hand, you need to use numpy's sqrt if you're taking the
square roots of all the elements of a numpy array. For functions such
as sqrt you would want to do something like this:

from math import sqrt as msqrt
from numpy import sqrt as nsqrt

Then you would use msqrt or nsqrt depending on the argument. The
machinery in __init__.py takes care of this for you and applies the
faster sqrt when the argument is a scalar.

Bruce Sherwood

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

Thanks a lot. This code looks *much* more Pythonic already.

On Thu, 16 Sep 2010 06:59:14 Bruce Sherwood wrote:
> Here's another successful test. I replaced the import statements at
> the start of the example program gas.py with the following import
> statements, and deleted the old Numeric code in a try structure:
> 
> 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)

Another possibility would be to just say

from visual import primitives

And then in the code you could create e. g. a cone using primitives.cone.

Much cleaner than trying to pull in *all* the individual objects into the 
local name space.

> from visual.ui import display
> import visual.crayola as color
> import visual.materials as materials

Do one like this here:

from visual import 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
> 
> This could have been more selective, since gas.py uses only a few of
> the vector and primitive features. Also, gas.py already has a scene =
> display(....) statement.
> 
> A subtle point that one should be aware of: In visual's __init__.py
> there is some complex machinery to deal with the fact that when, for
> example, you're taking the square root of a scalar you want to use the
> math module's sqrt, because it is much faster than using numpy's sqrt.
> On the other hand, you need to use numpy's sqrt if you're taking the
> square roots of all the elements of a numpy array. For functions such
> as sqrt you would want to do something like this:
> 
> from math import sqrt as msqrt
> from numpy import sqrt as nsqrt

Then why "rename" these things? Just import math and numpy directly and use 
numpy.sqrt() or math.sqrt()

This is *much* more clear ("explicit is better than implicit"), as otherwise 
users might be digging through the Python/NumPy docs to look for the 
description of msqrt or nsqrt.

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. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[James M. <mu...@pi...>]

> * For newbie's convenience, provide a "physicists make happy" package that
>   does the wild card imports all across the board.
>   (Even though I'm of the opinion that this dirty short cut creates more
>   head scratching in the future than it helps up front ...)
Guy,
	I have to admit that I am a bit offended by the "physicist make happy" comments.  What is being referred to here are in general NOT physicists.  Bruce's target audience is College Freshmen, (mainly future engineers), who have never taken any programing course.  Bruce wants to allow them to investigate their course material visually, and uses the python environment to do that.  The concept of namespace is lost on them.  I know, as I am teaching some of them right now.  In their "computing for freshman engineers" course, they are currently learning excel.  Next term they plan to teach them Matlab.  They don't know variables; they don't know for or while loops; they don't know physics; THEY DON'T KNOW ANYTHING!  So don't call them physicists.
	Other than that, I agree with everything you said.  What I would like to see is something like matplotlib where they cleaned up the code but kept the pylab module to preserve functionality.  People who know what they are doing, might do

import numpy as np
import matplotlib.pyplot as plt
import scipy

etc.  but one can also just do

import pylab

which ends up importing all sorts of things into the pylab namespace (I am not sure how much).  And again most people continue to use it as 

from pylab import *

We can cringe, and tell them not to do it, but it was important that the option was preserved.  The matplotlib people provide the option but also provide ways to do things properly.  I see the same thing in this case.  If the code could be rearranged to have proper granularity and allow people to use namspaces properly, that would be great!  WE do not need to use the "visual" name for that.  Then "visual" can just be something that imports everything to reproduce the current visual namespace.  We don't need to care as we can use the "correct" imports, as long as they exist and are documented.  From Bruce's mail, it seems like the option is there to separate the namespaces. whether this is the correct separation, I don't know, but seeing all the things visual currently loads into one namespace is great.  I can start to use things properly.  Most of my students will still "from visual import *", but I have something to tell those who do know a little programming.

As always, the devil is in the details, but I think this thread will continue.

-Jim

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

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

On Thu, 16 Sep 2010 11:42:30 James Mueller wrote:
>         I have to admit that I am a bit offended by the "physicist make
> happy" comments.  What is being referred to here are in general NOT
> physicists. 

Sorry, no offence intended. But the "physicists" were just the ones commonly 
used here as a representative group of users that are not Computer Scientists.

If this is a feature needed for this or similar groups, then that's fine. It 
would be just a huge shame if the visual package therefore would be spoiled 
for more users with more ambitious Python/programming knowledge.

> Bruce's target audience is College Freshmen, (mainly future
> engineers), who have never taken any programing course.  Bruce wants to
> allow them to investigate their course material visually, and uses the
> python environment to do that.  The concept of namespace is lost on
> them.  I know, as I am teaching some of them right now.  In their
> "computing for freshman engineers" course, they are currently learning
> excel.  Next term they plan to teach them Matlab.  They don't know
> variables; they don't know for or while loops; they don't know physics;
> THEY DON'T KNOW ANYTHING!  So don't call them physicists.

Again, sorry for that, it was just the common nomination previously here.

BTW, I'm an engineer myself (chemical engineer), and the concepts involved are 
not hard to understand. Python is also being taught to engineers at Auckland 
University (one of our PUG members teaches them), and they've got no problems 
to understand. After all, engineers are technical and logically thinking 
people, so they've got what it takes to think in systematic ways.

> Other than that,
> I agree with everything you said.  What I would like to see is something
> like matplotlib where they cleaned up the code but kept the pylab module
> to preserve functionality.  People who know what they are doing, might do
> 
> import numpy as np
> import matplotlib.pyplot as plt
> import scipy
> 
> etc.  but one can also just do
> 
> import pylab
> 
> which ends up importing all sorts of things into the pylab namespace (I am
> not sure how much).  And again most people continue to use it as 
> 
> from pylab import *
> 
> We can cringe, and tell them not to do it, but it was important that the
> option was preserved.  The matplotlib people provide the option but also
> provide ways to do things properly.  I see the same thing in this
> case.  If the code could be rearranged to have proper granularity and
> allow people to use namspaces properly, that would be great!  WE do not
> need to use the "visual" name for that.  Then "visual" can just be
> something that imports everything to reproduce the current visual
> namespace.  We don't need to care as we can use the "correct" imports, as
> long as they exist and are documented.  From Bruce's mail, it seems like
> the option is there to separate the namespaces. whether this is the
> correct separation, I don't know, but seeing all the things visual
> currently loads into one namespace is great.  I can start to use things
> properly.  Most of my students will still "from visual import *", but I
> have something to tell those who do know a little programming.

My biggest issue with the current way visual handles things is, that it 
imports all kinds of non-visual related things from the math and numpy 
packages. And it would get even worse if things imported then are also being 
renamed ("from spam import eggs as seggs").

Namespaces back and forth, certain things just shouldn't be pulled in by a 
base package named visual, that are completely unrelated.

> As always, the devil is in the details, but I think this thread will
> continue.

Yes, indeed. And the issue can only be resolved if it's being discussed.

Only with positive intentions,

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. 9266   fax: +64 9 441-8181
G....@ma... http://www.massey.ac.nz/~gkloss

Re: [Visualpython-users] Beta test version of VPython for Python 3.1 for Windows

[Craig S. <cra...@ma...>]

I like Jim's example of matplotlib: a simple package (pylab) for some users, but more pythonic imports for python experts.

Jim's point of very novice users is important to me. We've used VPython to teach high school teachers from a variety of disciplines. The approach of

from visual import *

to include a wide range of useful classes, functions, etc. is a quick way to get the teachers (and hopefully their students) going. Computationally oriented people (e.g., engineers, computer scientists, mathematicians, etc.) are only a small portion of the audience I target.

It could be argued another tool is more appropriate, but the fact that Python scales well from small scripts for novices to large scientific computing applications for experts is very appealing.

So, with some effort, I think VPython can have it both ways. I believe it should.

    Craig

On Sep 15, 2010, at 7:59 PM, Guy K. Kloss wrote:

> On Thu, 16 Sep 2010 11:42:30 James Mueller wrote:
>>        I have to admit that I am a bit offended by the "physicist make
>> happy" comments.  What is being referred to here are in general NOT
>> physicists. 
> 
> Sorry, no offence intended. But the "physicists" were just the ones commonly 
> used here as a representative group of users that are not Computer Scientists.
> 
> If this is a feature needed for this or similar groups, then that's fine. It 
> would be just a huge shame if the visual package therefore would be spoiled 
> for more users with more ambitious Python/programming knowledge.
> 
>> Bruce's target audience is College Freshmen, (mainly future
>> engineers), who have never taken any programing course.  Bruce wants to
>> allow them to investigate their course material visually, and uses the
>> python environment to do that.  The concept of namespace is lost on
>> them.  I know, as I am teaching some of them right now.  In their
>> "computing for freshman engineers" course, they are currently learning
>> excel.  Next term they plan to teach them Matlab.  They don't know
>> variables; they don't know for or while loops; they don't know physics;
>> THEY DON'T KNOW ANYTHING!  So don't call them physicists.
> 
> Again, sorry for that, it was just the common nomination previously here.
> 
> BTW, I'm an engineer myself (chemical engineer), and the concepts involved are 
> not hard to understand. Python is also being taught to engineers at Auckland 
> University (one of our PUG members teaches them), and they've got no problems 
> to understand. After all, engineers are technical and logically thinking 
> people, so they've got what it takes to think in systematic ways.
> 
>> Other than that,
>> I agree with everything you said.  What I would like to see is something
>> like matplotlib where they cleaned up the code but kept the pylab module
>> to preserve functionality.  People who know what they are doing, might do
>> 
>> import numpy as np
>> import matplotlib.pyplot as plt
>> import scipy
>> 
>> etc.  but one can also just do
>> 
>> import pylab
>> 
>> which ends up importing all sorts of things into the pylab namespace (I am
>> not sure how much).  And again most people continue to use it as 
>> 
>> from pylab import *
>> 
>> We can cringe, and tell them not to do it, but it was important that the
>> option was preserved.  The matplotlib people provide the option but also
>> provide ways to do things properly.  I see the same thing in this
>> case.  If the code could be rearranged to have proper granularity and
>> allow people to use namspaces properly, that would be great!  WE do not
>> need to use the "visual" name for that.  Then "visual" can just be
>> something that imports everything to reproduce the current visual
>> namespace.  We don't need to care as we can use the "correct" imports, as
>> long as they exist and are documented.  From Bruce's mail, it seems like
>> the option is there to separate the namespaces. whether this is the
>> correct separation, I don't know, but seeing all the things visual
>> currently loads into one namespace is great.  I can start to use things
>> properly.  Most of my students will still "from visual import *", but I
>> have something to tell those who do know a little programming.
> 
> My biggest issue with the current way visual handles things is, that it 
> imports all kinds of non-visual related things from the math and numpy 
> packages. And it would get even worse if things imported then are also being 
> renamed ("from spam import eggs as seggs").
> 
> Namespaces back and forth, certain things just shouldn't be pulled in by a 
> base package named visual, that are completely unrelated.
> 
>> As always, the devil is in the details, but I think this thread will
>> continue.
> 
> Yes, indeed. And the issue can only be resolved if it's being discussed.
> 
> Only with positive intentions,
> 
> 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. 9266   fax: +64 9 441-8181
> G....@ma... http://www.massey.ac.nz/~gkloss
> ------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev_______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

--
Craig A. Struble, Ph.D. | Marquette University
Associate Professor of Computer Science | 369 Cudahy Hall
(414)288-3783 | (414)288-5472 (fax)
http://www.mscs.mu.edu/~cstruble | cra...@ma...