visualpython-users

[Visualpython-users] Let's hash out the documentation for restrictive imports

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

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

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

I'll immediately offer an alternative. Suppose there is in the visual
folder a file vobjects.py containing this:

from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                               frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                               points, text, distant_light, local_light)

Then you could do this:

import visual.vobjects as vo
c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Would this be preferable to the following?

from visual.primitives import curve
c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Similarly, there could be a visual/vector.py file for the vector stuff
(vector, mag, etc.). There are already visual.crayola and
visual.materials files of this kind.

Bruce Sherwood

P.S. You might be wondering where numpy comes into this, considering
that for example the pos attribute of curve is a numpy array. The
numpy machinery is imported into the C++ component of Visual by
__init__.py, which is executed when you import (say) visual.primitive.
In the tiny program above, if you print(type(c.pos)) you'll see <class
'numpy.ndarray'>, and if you print(3*c.pos)) you'll see a 3 by 3 array
displayed that is 3 times that of c.pos. But your own namespace
doesn't contain numpy's array object, and trying to set b =
array([1,2,3]) gives an error: array not defined.

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

In this context, we could invent conventions for the "as" name, such
as "import visual.objects as vo", as has been done by the scipy.org
community. Here is what they say at
http://docs.scipy.org/doc/scipy/reference/tutorial/general.html:

For brevity and convenience, we will often assume that the main
packages (numpy, scipy, and matplotlib) have been imported as:

>>> import numpy as np
>>> import scipy as sp
>>> import matplotlib as mpl
>>> import matplotlib.pyplot as plt

These are the import conventions that our community has adopted after
discussion on public mailing lists. You will see these conventions
used throughout NumPy and SciPy source code and documentation. While
we obviously don’t require you to follow these conventions in your own
code, it is highly recommended.

On Wed, Sep 15, 2010 at 10:54 PM, Bruce Sherwood <bas...@nc...> wrote:
> I'll immediately offer an alternative. Suppose there is in the visual
> folder a file vobjects.py containing this:
>
> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>                               frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                               points, text, distant_light, local_light)
>
> Then you could do this:
>
> import visual.vobjects as vo
> c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
>
> Would this be preferable to the following?
>
> from visual.primitives import curve
> c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
>
> Similarly, there could be a visual/vector.py file for the vector stuff
> (vector, mag, etc.). There are already visual.crayola and
> visual.materials files of this kind.
>
> Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

Some VPython users have from time to time expressed a strong desire to
be able to import Visual selectively, without including math and
numpy, and recently I showed how to do this.

Over a week ago I asked for feedback on the best way to document this,
and I really do need your feedback, especially because one of the
schemes I proposed would require not just documentation but also new
files vobjects.py and vectors.py to be included in the Visual package.

If selective import matters to you, please post a note about your
preferences on how you would like to see this documented, and whether
you want files vobjects.py and vectors.py to be part of the package.
Thanks.

Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Symion <kn...@ip...>]

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 28/09/2010 2:17 AM, Bruce Sherwood wrote:
    <blockquote
      cite="mid:AANLkTi=B_d...@ma..."
      type="cite">
      <pre wrap="">Some VPython users have from time to time expressed a strong desire to
be able to import Visual selectively, without including math and
numpy, and recently I showed how to do this.

Over a week ago I asked for feedback on the best way to document this,
and I really do need your feedback, especially because one of the
schemes I proposed would require not just documentation but also new
files vobjects.py and vectors.py to be included in the Visual package.

If selective import matters to you, please post a note about your
preferences on how you would like to see this documented, and whether
you want files vobjects.py and vectors.py to be part of the package.
Thanks.

Bruce Sherwood

</pre>
    </blockquote>
    Hi there,<br>
        This is probably a naive question, but why not implement visual
    the same way as the other modules?<br>
    <br>
    EXAMPLE:<br>
    <br>
    import visual as vp<br>
    import scipy as sp<br>
    import matplotlib as mpl<br>
    import matplotlib.pyplot as plt<br>
    from visual.graph import (gdisplay, gcurve, gvbars, gdots,
    ghistogram)<br>
    <br>
    oscillation = gdisplay(xtitle='Time', ytitle='Response')<br>
    funct1 = gcurve(color=vp.color.cyan)<br>
    funct2 = gvbars(delta=0.5, color=vp.color.red)<br>
    funct3 = gdots(color=vp.color.yellow)<br>
    <br>
    for t in vp.arange(-30, 74, 1):<br>
        funct1.plot(pos=(t, 5.0+5.0*vp.cos(-0.2*t)*vp.exp(0.015*t)))<br>
        funct2.plot(pos=(t, 2.0+5.0*vp.cos(-0.1*t)*vp.exp(0.015*t)))<br>
        funct3.plot(pos=(t, 0.0+5.0*vp.cos(-0.03*t)*vp.exp(0.015*t)))<br>
    <br>
    histo = gdisplay(title='Histogram', x=0, y=400,
    width=800,height=400)<br>
    datalist1 = [5, 37, 12, 21, 25, 28, 8, 63, 52, 75, 7]<br>
    data = ghistogram(bins=vp.arange(-20, 80, 10), color=vp.color.red)<br>
    data.plot(data=datalist1) <br>
    datalist2 = [7, 23, 25, 72, -15]<br>
    data.plot(data=datalist2, accumulate=1)<br>
    <br>
    print dir()<br>
    <br>
    *****<br>
    <br>
    One might say I have simply swept any problem under a carpet called
    'vp', but if the problem is with<br>
    the global namespace issue and/or the need to conform to a Pythonic
    style then:<br>
        This  instantiation method conforms to standard python fair<br>
        The number of items in the namespace is now reduced to a
    handful.<br>
        And the slightly modified 'examples' program seems to works fine
    -  on my system?<br>
    <br>
  </body>
</html>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

The issue is that importing visual also imports math and numpy, and
does some tricky stuff to make sure that, for example, sqrt(scalar)
uses the fast math.sqrt routine, not the numpy.sqrt routine which is
much slower when acting on scalars.

For a large group of casual users, and for backward compatibility with
sizable numbers of programs in existence, it is important that "from
visual import *" continue to behave as it has in the past. Note that
"import visual as vp" also imports math and numpy, so that you'll find
that vp.sqrt(3) does not give an error, nor does
vp.sqrt(vp.array([3,3,3])).

For a small but important group of expert users, it is important to
have a way to import the visual objects and vector operations without
importing anything else, and I've proposed a couple of different
approaches, one of which requires including a couple of new files in
the visual directory.

What I'm seeking is which of these approaches for experts (or a
different one) is the one the experts would prefer to be documented
and encouraged.

Bruce Sherwood

On Thu, Oct 7, 2010 at 11:39 AM, Symion <kn...@ip...> wrote:
> Hi there,
>     This is probably a naive question, but why not implement visual the same
> way as the other modules?

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

On Thu, Oct 7, 2010 at 2:25 PM, Bruce Sherwood <bas...@nc...> wrote:
>
> For a large group of casual users, and for backward compatibility with
> sizable numbers of programs in existence, it is important that "from
> visual import *" continue to behave as it has in the past.

i know you have stated this a few times, but i'm just not clear to
this requirement.  forgive my ignorance, as i'm neither a professor
nor a student, only a professional developer, so my viewpoint is
likely biased :-)

what i don't understand, is how "from visual import *" actually makes
anything easier for the student/learner.  when someone (student) does
that, they don't even know what they just did, until someone else
(professor) tells them "ok, now this line will pull in X, Y, Z and the
rest of the alphabet for you to use", what's the difference in simply
explaining "ok, now pull/import the things you need; here is an
exhaustive list of what you might need".

either way the student must be explicitly told what is available.  at
least with explicit imports, they know exactly what is available in
the current program.  it seems much better in the long run for the
personal development of the student to not only show how, but also
_why_.

but again, i have little experience directing others.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

Okay, don't take it from me. See the postings on September 15 by James
Mueller and Craig Struble who, like me, have extensive experience
teaching novices to write small Python and/or VPython programs.

If you're not convinced, that's fine, but I will say as clearly as I
can: The current scheme will not be changed. That is simply not up for
discussion.

What is up for discussion is how best to accommodate the interests and
needs of expert programmers, including those who on this mailing list
have called for some scheme by which they can avoid importing stuff
they don't want to import. I've offered several ways to address this
need, and I'm asking for input on which scheme you think is best, on
how best to document it, and what conventions should be encouraged
(such as the scipy community settling on "import numpy as np").

Please give me useful feedback on this! Maybe you're offended by the
current behavior of "from visual import *" (or of "from pylab import
*"; see http://www.scipy.org/PyLab), in which case you should't use
it, but please don't waste time trying to convince me why it must be
abolished, because it will stay.

Bruce Sherwood

On Thu, Oct 7, 2010 at 2:04 PM, C Anthony Risinger <an...@ex...> wrote:
> On Thu, Oct 7, 2010 at 2:25 PM, Bruce Sherwood <bas...@nc...> wrote:
>>
>> For a large group of casual users, and for backward compatibility with
>> sizable numbers of programs in existence, it is important that "from
>> visual import *" continue to behave as it has in the past.
>
> i know you have stated this a few times, but i'm just not clear to
> this requirement.  forgive my ignorance, as i'm neither a professor
> nor a student, only a professional developer, so my viewpoint is
> likely biased :-)
>
> what i don't understand, is how "from visual import *" actually makes
> anything easier for the student/learner.  when someone (student) does
> that, they don't even know what they just did, until someone else
> (professor) tells them "ok, now this line will pull in X, Y, Z and the
> rest of the alphabet for you to use", what's the difference in simply
> explaining "ok, now pull/import the things you need; here is an
> exhaustive list of what you might need".
>
> either way the student must be explicitly told what is available.  at
> least with explicit imports, they know exactly what is available in
> the current program.  it seems much better in the long run for the
> personal development of the student to not only show how, but also
> _why_.
>
> but again, i have little experience directing others.
>
> C Anthony
>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Guenter S. <Gue...@ph...>]

Why not choose a new name for the pythonic way of importing visual and 
keep the current visual name for the catch all import that is desired 
for physics students who have don't know python. For example

import vispy as vp

does what python programmers want it to do and

from visual import *

does what it has always done. And of course there is probably a much 
better name than vispy.

Guenter Schneider

-- 
Guenter Schneider
http://www.physics.oregonstate.edu/~schneidg

On 10/07/2010 03:26 PM, Bruce Sherwood wrote:
> Okay, don't take it from me. See the postings on September 15 by James
> Mueller and Craig Struble who, like me, have extensive experience
> teaching novices to write small Python and/or VPython programs.
>
> If you're not convinced, that's fine, but I will say as clearly as I
> can: The current scheme will not be changed. That is simply not up for
> discussion.
>
> What is up for discussion is how best to accommodate the interests and
> needs of expert programmers, including those who on this mailing list
> have called for some scheme by which they can avoid importing stuff
> they don't want to import. I've offered several ways to address this
> need, and I'm asking for input on which scheme you think is best, on
> how best to document it, and what conventions should be encouraged
> (such as the scipy community settling on "import numpy as np").
>
> Please give me useful feedback on this! Maybe you're offended by the
> current behavior of "from visual import *" (or of "from pylab import
> *"; see http://www.scipy.org/PyLab), in which case you should't use
> it, but please don't waste time trying to convince me why it must be
> abolished, because it will stay.
>
> Bruce Sherwood
>
> On Thu, Oct 7, 2010 at 2:04 PM, C Anthony Risinger<an...@ex...>  wrote:
>> On Thu, Oct 7, 2010 at 2:25 PM, Bruce Sherwood<bas...@nc...>  wrote:
>>>
>>> For a large group of casual users, and for backward compatibility with
>>> sizable numbers of programs in existence, it is important that "from
>>> visual import *" continue to behave as it has in the past.
>>
>> i know you have stated this a few times, but i'm just not clear to
>> this requirement.  forgive my ignorance, as i'm neither a professor
>> nor a student, only a professional developer, so my viewpoint is
>> likely biased :-)
>>
>> what i don't understand, is how "from visual import *" actually makes
>> anything easier for the student/learner.  when someone (student) does
>> that, they don't even know what they just did, until someone else
>> (professor) tells them "ok, now this line will pull in X, Y, Z and the
>> rest of the alphabet for you to use", what's the difference in simply
>> explaining "ok, now pull/import the things you need; here is an
>> exhaustive list of what you might need".
>>
>> either way the student must be explicitly told what is available.  at
>> least with explicit imports, they know exactly what is available in
>> the current program.  it seems much better in the long run for the
>> personal development of the student to not only show how, but also
>> _why_.
>>
>> but again, i have little experience directing others.
>>
>> C Anthony
>>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2&  L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

On Thu, Oct 7, 2010 at 5:26 PM, Bruce Sherwood <bas...@nc...> wrote:
> Okay, don't take it from me. See the postings on September 15 by James
> Mueller and Craig Struble who, like me, have extensive experience
> teaching novices to write small Python and/or VPython programs.
>
> If you're not convinced, that's fine, but I will say as clearly as I
> can: The current scheme will not be changed. That is simply not up for
> discussion.

My intent was not to convince nor offend you.  I presented a simple
rationale for how, in my opinion, imports being present are
_beneficial_.  As I said, you are still telling the students what is
available (though now they can't actually _see_ it!)... they don't
magically know what's available; so yeah, I guess I don't buy it, but
as you've alluded, my purchase is not necessary.

I have followed this list quietly for years, so I am aware of previous
threads.  The posts you've directed to are mostly devoid of content,
and ultimately recommend nearly the exact solution I proposed at the
beginning of the same thread.

> What is up for discussion is how best to accommodate the interests and
> needs of expert programmers, including those who on this mailing list
> have called for some scheme by which they can avoid importing stuff
> they don't want to import. I've offered several ways to address this
> need, and I'm asking for input on which scheme you think is best, on
> how best to document it, and what conventions should be encouraged
> (such as the scipy community settling on "import numpy as np").

Best?  The best solution is to provide a package that behaves as any
other quality pythonic/stdlib package; it is logically separated into
component modules, each piece can be cleanly imported, and you only
ever get what you ask for.  I (the developer) run the show here, and I
don't like my machine to do any more than I request.

Now, as established, this does not need to be provided by the "visual"
namespace; it could be "libvisual" (my preference), or "vpython", or
"vispy" or even "visual.strict", etc.  What I don't want, is needing
to remember special ways to import to avoid the pollution etc. etc.,
because the (top-level) package is making grand assumptions about how
it will be used... else I'll just keep doing "import visual" and wade
through that.

It is my strong opinion that convenience and shortcuts are second to
flexibility and interoperability.

There may even be a way to do some __all__ magic so that the "visual"
package can work both ways out-of-the-box, but I'm not sure.

> Please give me useful feedback on this! Maybe you're offended by the
> current behavior of "from visual import *" (or of "from pylab import
> *"; see http://www.scipy.org/PyLab), in which case you should't use
> it, but please don't waste time trying to convince me why it must be
> abolished, because it will stay.

No, not offended whatsoever.  The problem is that this entire
discussion is not really about "novice" vs. "expert" developers; the
real issue at hand is _how_ the package expects (assumes) the
developer will be using it.  Your students/novices/whatever are using
visual as a standalone tool, with next to nothing, if anything, else!
On the flip-side, those like me, use visual as a spectacular
component/library to much larger composite works, where visual may
play anywhere from lead role to background extra.  I think many want
to see it [visual] easy to embed, etc.  Who knows where it could end
up with a strong focus beyond the classroom.

So, please understand that we are all on the same side here; everyone
on this list has some investment in the project.  As much as
novices/niche users are annoyed by namespaces/explicit
directives/etc., integrators/experienced users are equally perturbed
by a seeming disinterest to learn and understand the proven guidelines
established by the community.

At any rate, visual is a wonderful tool; passions from any direction
only reaffirm the awe inspiring power of this package.  I'm confident
a good solution exists :-), and personally I like the matplotlib/pylab
(ie. libvisual/visual) route.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

Bruce,

On Oct 7, 2010, at 3:25 PM, Bruce Sherwood wrote:

> The issue is that importing visual also imports math and numpy, and
> does some tricky stuff to make sure that, for example, sqrt(scalar)
> uses the fast math.sqrt routine, not the numpy.sqrt routine which is
> much slower when acting on scalars.

Is this really an issue?  If you do

> import numpy as np
> import scipy as sp
> import visual as vp
> 
> a=np.sqrt(5)

Does the fact that the vp namespace also includes numpy and math affect this (other than bloat)?

on the other hand

> from visual import *
> from numpy import *

Now you have replaced the visual version of sqrt with its check, with just the numpy one.

I think what you are getting at is a questions of whether it is OK for visual to import math and numpy into its own namespace, and if not, how should visual do this branch?  I don't really consider myself enough of an expert to comment.  Perhaps someone else does. 

Actually it looks like visual imports cmath as well.
> >>> a=-1
> >>> vp.sqrt([a])
> array([ NaN])
> >>> vp.sqrt(a)
> 
> Traceback (most recent call last):
>   File "<pyshell#16>", line 1, in <module>
>     vp.sqrt(a)
>   File "/Library/Frameworks/Python.framework/Versions/Current/lib/python2.6/site-packages/visual/__init__.py", line 45, in _uf
>     if type(x) in mathtypes: return math(x)
> ValueError: math domain error
> >>> b=-1+0j
> >>> vp.sqrt(b)
> 1j
> >>> vp.sqrt([b])
> array([ 0.+1.j])

-Jim

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Lenore H. <lh...@si...>]

From my perspective of wanting to use Visual to let physics students work with problems they can't solve analytically (at least not at their math level), having to start off with one line of "this gives us access to the tools we need" rather than 5 or 10 lines of the same makes a lot of sense.  I'm NOT teaching programming in that case.  All of the import and scene creation stuff is noise that we have to get past to get to the modeling.  I admit I'm trying to have my cake and eat it too.  I like the output and scene control available in visual better than in the Easy Java Simulation program but I'd like to minimize the programming aspects the way EJS does.    For me, Visual is a modeling tool not a programming tool.  

Lenore Horner

On Oct 7, 2010, at 4:04 PM, C Anthony Risinger wrote:

> On Thu, Oct 7, 2010 at 2:25 PM, Bruce Sherwood <bas...@nc...> wrote:
>> 
>> For a large group of casual users, and for backward compatibility with
>> sizable numbers of programs in existence, it is important that "from
>> visual import *" continue to behave as it has in the past.
> 
> i know you have stated this a few times, but i'm just not clear to
> this requirement.  forgive my ignorance, as i'm neither a professor
> nor a student, only a professional developer, so my viewpoint is
> likely biased :-)
> 
> what i don't understand, is how "from visual import *" actually makes
> anything easier for the student/learner.  when someone (student) does
> that, they don't even know what they just did, until someone else
> (professor) tells them "ok, now this line will pull in X, Y, Z and the
> rest of the alphabet for you to use", what's the difference in simply
> explaining "ok, now pull/import the things you need; here is an
> exhaustive list of what you might need".
> 
> either way the student must be explicitly told what is available.  at
> least with explicit imports, they know exactly what is available in
> the current program.  it seems much better in the long run for the
> personal development of the student to not only show how, but also
> _why_.
> 
> but again, i have little experience directing others.
> 
> C Anthony
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

On Thu, Oct 7, 2010 at 6:58 PM, Lenore Horner <lh...@si...> wrote:
> From my perspective of wanting to use Visual to let physics students work with problems
> they can't solve analytically (at least not at their math level), having to start off with one line
> of "this gives us access to the tools we need" rather than 5 or 10 lines of the same makes a
> lot of sense.  I'm NOT teaching programming in that case.

And that is understandable, but it only works for a single use case:
Visual as a standalone tool, in it's own environment.  While this may
indeed be the prevalent use case at the moment, a narrow focus here is
really going to cripple Visual's appeal to other avenues and
developers who may later hack on the core; students are *never* going
to help make Visual itself any better, and lack of a stable
library/API make it a moving target for integrators.

Since it's clear that the "visual" namespace is frozen, I really think
we just need to create a new package, say "libvisual", whose focus is
to be agnostic to how it's being used, and as flexible as possible.
then...

> All of the import and scene creation stuff is noise that we have to get past to get to the
> modeling.  I admit I'm trying to have my cake and eat it too.  I like the output and scene
> control available in visual better than in the Easy Java Simulation program but I'd like to
> minimize the programming aspects the way EJS does.

"visual", if following the above, will eventually be reduced to a
meeting ground of various tools being imported from libvisual, numpy,
etc., and will barely do _anything_ itself.  All functionality will be
encompassed by the library python module [libvisual], which itself
will interact with the C (or is it C++) module.

You could then go ballistic adding convenience functions and whatnot,
like quickstart(), to build a scene, etc., without affecting
integrators, and without affecting the stable-esque API of libvisual.

This was why I originally suggested something like:

from visual.presets.physics import *

or similar, as then there would be an actual namespace to put various
"shortcut" modules to build preconfigured environments, and it's a
small change compared to what's currently done; though I don't know
how much demand there would be for something like this.

> For me, Visual is a modeling tool not a programming tool.

For me, it's a generic tool for rendering and controlling 3D
environments in a natural and intuitive way from Python.  In my
far-from-finished-on-the-back-burner-for-now-data-aggregation-tool,
Visual is simply part of a plugin that could render real-time data to
a 3D environment; the tool itself uses SSH libraries, protocol
buffers, other GUI libraries, and a smattering of other utilities.
Visual was so cool; within a couple days and far less code, I had a
clone of gltail (http://www.fudgie.org/), since I didn't have to deal
with OpenGL directly.

Anyway, I'm just trying to stress that (IMO) the focus should be on a
building a quality 3D graphics python library, reusable by anyone in a
variety of capacities; the other stuff is icing on said cake.

C Anthony

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

I've been awefully quiet in this whole discussion, even though I believe it 
was me who's stirred up some waves in trying to get some more Python sanity 
into Visual (sanity as in to behave like every other well behaved Python 
module does).

Reading happily along, and I must say that C Anthony is speaking (writing) out 
*exactly* my feeling/impression. So there's no need to repeat that. (Thanks C 
Anthony!!!)

Anyway, I like the proposal to make "visual" (the module) a convenience module 
that keeps backwards compatibility with the previously large local namespace, 
and make another one the well behaved "cleanroom" module, from which the 
"visual" module then pulls. Along those lines was also a good year (?) back my 
patch that I have provided to pull this off. As Visual (the project) is also 
commonly known as VPython, I think a suitable module name for the clean module 
would be either "vpython" or as also suggested "libvisual". Although the 
latter too much for me connotates with the shared library binary file on UN*X 
like systems.

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] Let's hash out the documentation for restrictive imports

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

I'm confused. I thought that what I'd proposed achieves the desired
effect, so I don't understand what the issue is. To repeat:

-----------------------------------------------------------------
Suppose there is in the visual folder a file vobjects.py containing this:

from .primitives import (arrow, cylinder, cone, sphere, box, ring,
     label,  frame, pyramid, ellipsoid, curve ,faces, convex,
     helix, points, text, distant_light, local_light)

Then you could do this:

import visual.vobjects as vo
c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Would this be preferable to the following?

from visual.primitives import curve
c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])

Similarly, there could be a visual/vector.py file for the vector stuff
(vector, mag, etc.). There are already visual.crayola and
visual.materials files of this kind.
-----------------------------------------------------------

In what way does this not meet expert needs?

Guy, I'm sorry, perhaps I was distracted at the time, but I don't
remember your having made a specific proposal. What I thought had
happened when you first brought this up was that you were studying the
issues. Is your solution very different from mine?

Bruce Sherwood

P.S. There is another import issue I failed to identify, which is that
the text object imports some font- and polygon-handling modules, and
some cleanup may be called for in the submodule file primitives.py.

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

I don't see vobjects as necessary, but maybe I am missing something. In every other Python module I've used, I can choose to either import module contents in its namespace:

import visual.primitives as vp

Or I can explicitly bring select functions, classes, etc. into the current namespace:

from visual.primitives import curve

I think anything outside the friendly visual package ought to behave like any typical standard Python package.

I also will add that Guy's proposal to make the clean version of the module be part of a different namespace (e.g. vpython, libvisual, visuallib [like matplotlib], or vispy [like scipy/numpy]) has merit. I do think it will be confusing and error prone to have the friendly visual module and the clean modules in similarly named name spaces.

    Craig

On Oct 7, 2010, at 9:26 PM, Bruce Sherwood wrote:

> I'm confused. I thought that what I'd proposed achieves the desired
> effect, so I don't understand what the issue is. To repeat:
> 
> -----------------------------------------------------------------
> Suppose there is in the visual folder a file vobjects.py containing this:
> 
> from .primitives import (arrow, cylinder, cone, sphere, box, ring,
>     label,  frame, pyramid, ellipsoid, curve ,faces, convex,
>     helix, points, text, distant_light, local_light)
> 
> Then you could do this:
> 
> import visual.vobjects as vo
> c = vo.curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
> 
> Would this be preferable to the following?
> 
> from visual.primitives import curve
> c = curve(pos=[(0,0,0), (1,0,0), (0,1,0)])
> 
> Similarly, there could be a visual/vector.py file for the vector stuff
> (vector, mag, etc.). There are already visual.crayola and
> visual.materials files of this kind.
> -----------------------------------------------------------
> 
> In what way does this not meet expert needs?
> 
> Guy, I'm sorry, perhaps I was distracted at the time, but I don't
> remember your having made a specific proposal. What I thought had
> happened when you first brought this up was that you were studying the
> issues. Is your solution very different from mine?
> 
> Bruce Sherwood
> 
> P.S. There is another import issue I failed to identify, which is that
> the text object imports some font- and polygon-handling modules, and
> some cleanup may be called for in the submodule file primitives.py.
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> 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...

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

Here's another possibility for the contents of a file in the visual
folder, perhaps called libvisual as has been suggested:

----------------------------------------------------
from . import cvisual
from .cvisual import (vector, mag, mag2, norm, cross, rotate,
                       comp, proj, diff_angle, rate, waitclose)
from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
                               frame, pyramid, ellipsoid, curve,
faces, convex, helix,
                               points, text, distant_light, local_light)
from . ui import display
from . import crayola
color = crayola
from . import materials
from . import site_settings
----------------------------------------------------

Then a program would look like this:

import visual.libvisual as vis
vis.display(width=600, height=600, background=vis.color.white)
vis.box(color=vis.color.orange, material=vis.materials.wood)
v = vis.vector(1,2,3)
....

Does this meet the requirements?

Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

[Lenore H. <lh...@si...>]

Well it looks like it keeps the one-line start, but at the cost of making most commands two or three letters longer.  Maybe that's inevitable, but it not only makes more typing for everything, it makes all the lines of code longer and therefore harder to read.

Lenore Horner

  
On Oct 8, 2010, at 12:39 AM, Bruce Sherwood wrote:

> Here's another possibility for the contents of a file in the visual
> folder, perhaps called libvisual as has been suggested:
> 
> ----------------------------------------------------
> from . import cvisual
> from .cvisual import (vector, mag, mag2, norm, cross, rotate,
>                       comp, proj, diff_angle, rate, waitclose)
> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>                               frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                               points, text, distant_light, local_light)
> from . ui import display
> from . import crayola
> color = crayola
> from . import materials
> from . import site_settings
> ----------------------------------------------------
> 
> Then a program would look like this:
> 
> import visual.libvisual as vis
> vis.display(width=600, height=600, background=vis.color.white)
> vis.box(color=vis.color.orange, material=vis.materials.wood)
> v = vis.vector(1,2,3)
> ....
> 
> Does this meet the requirements?
> 
> Bruce Sherwood
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

No, please understand that for novice/casual use one could still use
"from visual import *". What this proposal addresses is the need of
expert users to be able to keep their namespaces clean, in situations
where Visual is just one component of many. In those situations people
WANT the specificity of saying vis.sphere (or vp.sphere, or whatever
abbreviation they want to specify, or whatever abbreviation we as a
community may wish to encourage).

So the question remains, does my proposal give the experts what they
need (without removing the simple scheme that some of us need)?

Bruce Sherwood

On Fri, Oct 8, 2010 at 4:50 AM, Lenore Horner <lh...@si...> wrote:
> Well it looks like it keeps the one-line start, but at the cost of making most commands two or three letters longer.  Maybe that's inevitable, but it not only makes more typing for everything, it makes all the lines of code longer and therefore harder to read.
>
> Lenore Horner
>
>
> On Oct 8, 2010, at 12:39 AM, Bruce Sherwood wrote:
>
>> Here's another possibility for the contents of a file in the visual
>> folder, perhaps called libvisual as has been suggested:
>>
>> ----------------------------------------------------
>> from . import cvisual
>> from .cvisual import (vector, mag, mag2, norm, cross, rotate,
>>                       comp, proj, diff_angle, rate, waitclose)
>> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>>                               frame, pyramid, ellipsoid, curve,
>> faces, convex, helix,
>>                               points, text, distant_light, local_light)
>> from . ui import display
>> from . import crayola
>> color = crayola
>> from . import materials
>> from . import site_settings
>> ----------------------------------------------------
>>
>> Then a program would look like this:
>>
>> import visual.libvisual as vis
>> vis.display(width=600, height=600, background=vis.color.white)
>> vis.box(color=vis.color.orange, material=vis.materials.wood)
>> v = vis.vector(1,2,3)
>> ....
>>
>> Does this meet the requirements?
>>
>> Bruce Sherwood

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

In a private conversation Craig Struble has helped me see another
structure that may be particularly appropriate. I believe his thinking
is in part based on Guy's suggestions.

Craig suggests implementing "a style of usage similar to the pylab
module, where the really pythonish stuff is all in matplotlib.foo
(where foo is some specific part of the API). A motivation for this is
that I believe the community of folks using matplotlib, numpy, and
scipy are potential users of visual. They will be familiar with the
matplotlib model." In site-packages there is a single file pylab.py
whose import gives you everything, and there's a folder matplotlib
containing the stuff that pylab.py imports. Mimicking this, there
would be a single file visual.py whose import gives you everything,
and a folder (maybe named "vpython") that would contain all the
submodules.

I pointed out that while we can arrange things in such a way as to
look like this, the actual implementation has to be "the other way
round": for backward compatibility the visual folder has to remain
essentially unchanged, and a second folder (maybe named "vpython")
would have submodules that would import from the visual folder. The
reason for this is that people may be importing from
visual.primitives, and they are certainly importing from visual.graph.

Bruce Sherwood

P.S. Incidentally, in the new vpython folder there should be a new
version of the graph module, because the existing one executes the
dreaded "from visual import *", and changing that in visual.graph
would cause problems, because people have been able to say just "from
visual.graph import *" and get spheres as well as graphs. The new
version, in the vpython folder, of course would not import spheres
etc.

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

On Sat, 09 Oct 2010 07:05:19 Bruce Sherwood wrote:
> I pointed out that while we can arrange things in such a way as to
> look like this, the actual implementation has to be "the other way
> round": for backward compatibility the visual folder has to remain
> essentially unchanged, and a second folder (maybe named "vpython")
> would have submodules that would import from the visual folder.

I think there's an error in the logic here. The implementation should be 
driven in a way that it is implemented cleanly first off the bat. Then you can 
put all kinds of imports into a "comfortability" module "visual".

If done the other way around, the runtime will be buggered with all the unused 
imports, and it is only the presentation that makes it look more pythonesque.

So my suggestion goes along the line to provide two independent name spaces: 
"vpython" (or "libvisual" or whatever suggestions Craig has made) for the 
clean implementation, and a separate one "visual" that contains the 
comfortability imports from the clean implementation.

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] Let's hash out the documentation for restrictive imports

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

On Fri, 08 Oct 2010 17:39:59 Bruce Sherwood wrote:
> Here's another possibility for the contents of a file in the visual
> folder, perhaps called libvisual as has been suggested:
> 
> ----------------------------------------------------
> from . import cvisual
> from .cvisual import (vector, mag, mag2, norm, cross, rotate,
>                        comp, proj, diff_angle, rate, waitclose)
> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>                                frame, pyramid, ellipsoid, curve,
> faces, convex, helix,
>                                points, text, distant_light, local_light)
> from . ui import display
> from . import crayola
> color = crayola
> from . import materials
> from . import site_settings
> ----------------------------------------------------

Why all these funky relative imports ("from . import foo")?

It should be much cleaner to just say "import foo"!

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] Let's hash out the documentation for restrictive imports

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

Are you saying that there should be two copies of key components in
the two folders (which I'll call "visual" and "vpython" for now)? I
would be nervous about the maintenance issues, although I guess
installers be built to put copies of files in two places. My intention
is that if the actual implementation is done right it should make no
difference whatsoever where the components are physically located,
that importing from the vpython folder will be completely clean,
independent of where the files are. If that's not achievable, then of
course you're right.

Bruce Sherwood

On Fri, Oct 8, 2010 at 2:55 PM, Guy K. Kloss <g....@ma...> wrote:
> On Sat, 09 Oct 2010 07:05:19 Bruce Sherwood wrote:
>> I pointed out that while we can arrange things in such a way as to
>> look like this, the actual implementation has to be "the other way
>> round": for backward compatibility the visual folder has to remain
>> essentially unchanged, and a second folder (maybe named "vpython")
>> would have submodules that would import from the visual folder.
>
> I think there's an error in the logic here. The implementation should be
> driven in a way that it is implemented cleanly first off the bat. Then you can
> put all kinds of imports into a "comfortability" module "visual".
>
> If done the other way around, the runtime will be buggered with all the unused
> imports, and it is only the presentation that makes it look more pythonesque.
>
> So my suggestion goes along the line to provide two independent name spaces:
> "vpython" (or "libvisual" or whatever suggestions Craig has made) for the
> clean implementation, and a separate one "visual" that contains the
> comfortability imports from the clean implementation.
>
> 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
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

This proposal assumed that the "libvisual" file was in the visual
folder, in which case I thought that relative imports were now
favored, for various reasons. As I understand it, the main issue is
that there could be a module named "foo" at a higher level in the
search path, in which case "import foo" might not pick up our foo, but
someone else's foo. Have I misunderstood something?

Bruce Sherwood

On Fri, Oct 8, 2010 at 2:57 PM, Guy K. Kloss <g....@ma...> wrote:
> On Fri, 08 Oct 2010 17:39:59 Bruce Sherwood wrote:
>> Here's another possibility for the contents of a file in the visual
>> folder, perhaps called libvisual as has been suggested:
>>
>> ----------------------------------------------------
>> from . import cvisual
>> from .cvisual import (vector, mag, mag2, norm, cross, rotate,
>>                        comp, proj, diff_angle, rate, waitclose)
>> from .primitives import (arrow, cylinder, cone, sphere, box, ring, label,
>>                                frame, pyramid, ellipsoid, curve,
>> faces, convex, helix,
>>                                points, text, distant_light, local_light)
>> from . ui import display
>> from . import crayola
>> color = crayola
>> from . import materials
>> from . import site_settings
>> ----------------------------------------------------
>
> Why all these funky relative imports ("from . import foo")?
>
> It should be much cleaner to just say "import foo"!
>
> 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
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> https://lists.sourceforge.net/lists/listinfo/visualpython-users
>
>

Re: [Visualpython-users] Let's hash out the documentation for restrictive imports

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

On Sat, 09 Oct 2010 10:41:35 Bruce Sherwood wrote:
> Are you saying that there should be two copies of key components in
> the two folders (which I'll call "visual" and "vpython" for now)? I
> would be nervous about the maintenance issues, although I guess
> installers be built to put copies of files in two places.

No no no. Absolutely not. The code is there only *once*, but as you're 
"mirroring in" parts of the NumPy and math name spaces, you'd be "mirroring 
in" all the stuff into the "visual" package from the "vpython" packages. So 
the "visual" package/module does not really contain any (significant) 
implementations, but just imports/aggregates the stuff from "around the 
house".

> My intention
> is that if the actual implementation is done right it should make no
> difference whatsoever where the components are physically located,
> that importing from the vpython folder will be completely clean,
> independent of where the files are.

Exactly, that's the way I (and probably the others putting up their votes for 
better Python cleanliness) have envisioned it.

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