visualpython-users

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

[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

[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

[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

[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

[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

[Visualpython-users] [ANN] git mirror at github

[Thomas S. <to...@fe...>]

Hi list,

for those of you, who prefer git over cvs, can clone the git repository
at github:
http://github.com/tomspur/python-visual

I intend to follow the cvs repository and push the changes to the
master tree there, if github let's me to, because it's just allowed to
have a 300MB repository, and vpython is already at 200MB. If the size
will be too big in the future, I'm afraid, I need to delete it again...


There is also a fedora_specific branch, in which I commited some
changes, so vpython works on fedora:
http://github.com/tomspur/python-visual/commits/fedora_specific

The latest two commits there could be merged into cvs too:
	- Deleting of include/config.h:
	  http://github.com/tomspur/python-visual/commit/fbe7f1c1c56059e0ceb5143a697809d0009ae610
	- sed -i 's/\r//' docs/visual/VisualRef.css
	  http://github.com/tomspur/python-visual/commit/0c881bb6db6edc637c2e5d387b31a72971d53e82

The file include/config.h is not needed, because that's regenerated
everytime with autoconfigure anyway and the second commit was noticed
in the review for inclusion in fedora.

Thanks,
  Thomas

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

[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

[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

[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

[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 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

[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

[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

[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

[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...>]

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

[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] Segmentation Fault

[Sanjoy M. <sa...@ol...>]

> Have you (or anybody in the list) found a fix for this annoyance? It
> makes my VPython applications unusable!

No fix, alas, just a confirmation that someone else (me) has the same
problem.  I don't know where the problem is, but in the hopes of getting
it wider notice and more eyes looking at it, I submitted a Debian bug
report:

<http://bugs.debian.org/598896>

If you want to add information to the bug-tracker report, you should be
able to mail to

  59...@bu...

-Sanjoy

`Until lions have their historians, tales of the hunt shall always
 glorify the hunters.'  --African Proverb

[Visualpython-users] Visual on Windows 7 64-bit

[Frank S. <fs...@am...>]

Hello; can anyone tell me if Visual will run on Window 7 64-bit. I have 
tried with Python 27 but I get the following error trying to import:

from visual import *

Traceback (most recent call last):
  File "<pyshell#1>", line 1, in <module>
    from visual import *
  File "C:\Python27\lib\site-packages\visual\__init__.py", line 59, in <module>
    import cvisual
ImportError: DLL load failed: %1 is not a valid Win32 application.

Thanks. 

Re: [Visualpython-users] movement in 3D and visibility in gdisplay

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

Here is an example:

from visual.graph import *

g = gdisplay()
c = gcurve(color=color.cyan)
c.plot(pos=(1,0))
c.plot(pos=(2,1))
print c.gcurve.pos # undocumented gcurve attribute; c.gcurve is a curve object
for y in arange(1,0.1,-.01):
    rate(40)
    c.gcurve.pos[1] = (2,y,0)
g.display.mouse.getclick()
c.gcurve.visible = False

Also note the following from the documentation on graphs:

Every gdisplay has the attribute "display", so you can place
additional labels or manipulate the graphing window. The only objects
that you can place in the graphing window are labels, curves, faces,
and points.

graph1 = gdisplay()
label(display=graph1.display, pos=(3,2), text="P")
graph1.display.visible = False # make the display invisible

You can zoom in a graph (use left+right mouse buttons), just as in any
VPython display. You can't rotate, because it's a 2D display.

Finally, note that visual.graph is written in pure Python, so if you
have special needs you might consider making an improved version.

Bruce Sherwood

On Tue, Sep 28, 2010 at 6:05 AM, Воробьев Владимир <Azi...@ya...> wrote:
> Hello!
> Could somebody tell about two things - movement  in (2D)3D and enabling visibility in gdisplay?
> I need some more flexibility with 2D-graph:
> I want to zoom and move some interesting details in my (2D)3D graph. Is it possible?
> The other thing I want to know:
> Does visibility work with objects graphed on gdisplay?
> Thank in advance.
>
> ------------------------------------------------------------------------------
> 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
>

[Visualpython-users] movement in 3D and visibility in gdisplay

[Воробьев В. <Azi...@ya...>]

Hello!
Could somebody tell about two things - movement  in (2D)3D and enabling visibility in gdisplay?
I need some more flexibility with 2D-graph:
I want to zoom and move some interesting details in my (2D)3D graph. Is it possible?
The other thing I want to know:
Does visibility work with objects graphed on gdisplay?
Thank in advance.

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

[Visualpython-users] Problem with dragging objects

[Reinhard O. <old...@ma...>]

  Dear All!
VPython is really agreat library that I love very much. But now I tried 
to make points dragable in a seemingly very simple way:

from visual import *

def Vmainloop():

     while 1:

         if scene.mouse.events:

             ev=scene.mouse.getevent()

             if ev.drag: VdragEvent(scene.mouse.pos,scene.mouse.pick)

def VdragEvent(pos,obj): obj.pos=pos

def makePoint(pos): return sphere(pos=pos,radius=0.2,color=color.red)

[A,B,C]=[makePoint((-3,1,1)),makePoint((3,1,1)),makePoint((0,5,1))]

scene.autoscale=0

Vmainloop()


However, this does not work. The points are draggable, but only a very 
small distance. After that, no further events are triggered. Obviously, 
after dragging it a bit, it is no longer picked. But this is strange 
because the position has been updated.

Does anybody have a hint on this?

Reinhard Oldenburg

-- 
Prof. Dr. Reinhard Oldenburg
Goethe-Universität Frankfurt
Institut für Didaktik der Mathematik und Informatik
Senckenberganlage 9
D-60325 Frankfurt/Main
Telefon  +49 (0)69 798 23770
Telefax  +49 (0)69 798 22553
E-Mail   old...@ma...
WWW      www.math.uni-frankfurt.de/~oldenbur